WebGL not supported from ASP.NET MVC page

[mwpowellhtx]

Hello,

I've tried a couple different event listeners, to no avail.

In a "simple" (i.e. non-ASP.NET) page, it works just fine, engine starts, I can build a scene, no problem.

However, when I embed my canvas in an ASP.NET MVC partial, then try and start the engine, I get "WebGL not supported".

The script is in the body, renders along with the other partials to Html. Nothing special about that.

window.addEventListener('DOMContentLoaded', function() {

    // get the canvas DOM element
    var canvas = $("#wizardCanvas");

    // load the 3D engine
    var engine = new BABYLON.Engine(canvas, true);

    var createScene = function() {

        // create a basic BJS Scene object
        var s = new BABYLON.Scene(engine);

        // connect with partial-provided scene handler
        (buildScene || (function() {}))(s);

        return s;
    };

    var scene = createScene();

    // run the render loop
    engine.runRenderLoop(function() {
        scene.render();
    });

    // the canvas/window resize event handler
    window.onresize(function() {
        engine.resize();
    });
});

I've also tried connecting with the onload event. No difference.

window.onload(function() {
    // ...
});

Here are my script references, via MVC script "bundles".

<script src="/Scripts/jquery-1.10.2.js"></script>

<script src="/Scripts/bootstrap.js"></script>
<script src="/Scripts/respond.js"></script>

<script src="/Scripts/jquery-ui-1.11.4.js"></script>

<script src="/Scripts/ExtensionsJS/str-1.0.3.js"></script>
<script src="/Scripts/ExtensionsJS/arr-1.0.1.js"></script>

<script src="/Scripts/Oimo.js"></script>
<script src="/Scripts/babylon.js"></script>
<script src="/Scripts/poly2tri.js"></script>

<script src="/Scripts/modernizr-2.6.2.js"></script>

Is there something about the server-side MVC rendering that is causing problems? And how else would I know that, per se?

Actually, I wonder if it is because my script references are in the incorrect order. I'll try that next.

Regards,

Michael Powell

[mwpowellhtx]

Apparently include order made no difference in this case.

[mwpowellhtx]

Which leads me to a key feasibility question.

As the user enters config input in the form, I want to respond to those form field changes and update the scene elements accordingly.

Probably, I need to learn how to persuade WebGL / babylon to play nice with my ASP.NET MVC rendered pages; all that is TBD.

[mwpowellhtx]

Duh, I figured it out. jQuery returned an array of matching elements, of which I want the first. i.e.

// ...
$("#wizardCanvas")[0]
// ...

 

[Temechon]

I love when a topic is already solved when I read it  Keep up the good work

[mwpowellhtx]

Mix in a little JavaScript, jQuery, and all of a sudden, I've got a way of signaling via jQuery among my partial views event when the scene is created. 

[MasterSplinter]

And the lesson learned is... Don't use jQuery

[mwpowellhtx]

@MasterSplinter I don't know what you're talking about. jQuery is working beautifully to connect created scene with the event handler that actually builds the scene.

[Pryme8]

I was scrolling down to anwser you and then bam, you had it... Love it when I watch people figure out their problems. ? Good deal keep it up!

@MasterSplinter

$. Is a must, if you have not used it yet you need to hop in head first today!!!

[MasterSplinter]

That was sarcasm guys. 

[RaananW]

I would say that non sarcastically. Don't use jQuery. Give me one reason to use it in a Babylon project... People tend to forget that jQuery IS JavaScript. It's not a new magical language. And it makes everything a bit slower. 

[jerome]

some logic

WebGL => html5 => real standard among browser editors  + really same shared API + querySelectors and other native stuff formerly done by jQuery => no real need for jQuery within BJS

[mwpowellhtx]

@MasterSplinter Sarcasm doesn't convey well through blogs and such. Not without having set up the context.

@RaananW @jerome Fair enough. I seem to recall reading some blog somewhere recently at how jQuery was going obsolete, for exactly these kinds of reasons. Specifically which reasons I couldn't tell you, but it bears further investigation. Thanks...

[MasterSplinter]

Some stuff is nice and requires fewer lines of code to do with jQuery.  But if you are only using it for class selectors that's just silly.

[mwpowellhtx]

@MasterSplinter I hear you.

But in my case, I'm using event mechanisms as well, which jQuery is pretty good at doing. Again, if there's a native alternative that is just as strong, would go native.

Look, I'm not defending what I am doing, just looking for stack thoughts. I appreciate the feedback.

[RaananW]

No one is attacking, so no defending is needed.  I think that eventually everyone's simply trying to help. I hope it comes out like this as well.

Whenever I see:

$.each(....)

I wonder if the person who implemented this knows how JavaScript has changed since ES3. What's wrong with the native forEach function?

jQuery is no magic. it uses native JavaScript functions. So when asking if there is a native alternative, my answer would be - it is already native

I am not sure what you mean with event mechanisms. if you refer to the almighty $(selector).on('eventname'.....), then using the addEventListener will work. The selector is the tricky part. This is what makes jQuery so loved by everyone, but also very slow. Luckily, most (if not all) browsers support http://www.w3schools.com/jsref/met_document_queryselector.asp so jQuery is mostly not needed 

I have nothing against jQuery in general. but a Babylon project is a WebGL project. It needs speed, and as little delay as possible between frames. And jQuery is not known for its amazing process speed. 

[jerome]

I agree 

16 ms only to do everything once the render loop is started ...

So it's better to keep the more straight forward and direct as possible in our own code and we need to keep in mind that BJS has also lots of operations to compute on its side in order to display our nicest ideas in 3D 

 

What is jQuery good for ?

It used to provide a good poyfill for older browsers that hadn't the wanted methods, it used to provide the way to write a cross-browser code only once (when the browser editors used to love to implement their own version of html or js), it used to give a nice way to have the query selectors.

But since HTML5 is out (and remember : if you are using WebGL, you are  necesseraly using HTML5), all the browser editors tend to converge to the same W3C standard (nearly 20 years after the browser war started, let's enjoy the peace now), they are even a part of the standard writers.

You don't have to care about the browser versions now (does this IE version have this way to do xmlHttpRequest ? how does this browser call this event ?  etc) if you code with BJS. It's HTML5 for everyone.

Just care about the perfs.

Moreover, HTML5 provides natively now what jQuery invented about the querySelector.. but faster. 

 

I personnaly keep on using jQuery, what is a wonderful lib, when I need to provide a web page to an unknown target (html 4.1, this should work on any browser... well, the more possible, even the oldest ones) or maybe a page with heavy DOM manipulations.

But if I know my code is explicitly  HTML5, I don't know what jQuery brings more. 

[mwpowellhtx]

@RaananW Fair enough. Like I said, the feedback is appreciated, it is good to know. For my part, I'm coming at this as though it were ES version 1 to me; I've worked with JavaScript in the past, and it's easy enough to prototype bits where I need them. Then, when I learn there are readily available bits, of course, it's good to know.

Anyhow, I've put this one to bed now.

Thanks all for the feedback.