Creating a WebGL context is slow, should only be done if needed

[bjacob]

I've come across some sites that create WebGL contexts on page load, when they really don't need them. These include github.com and economist.com.

Creating a WebGL context forces the browser to synchronously create a OpenGL context. That is slow, in a way that the browser can't control (depends on OS and drivers). To give you an order of magnitude, on linux, OpenGL context creation typically takes:

• 50 ms with Mesa drivers
• 120 ms with NVIDIA driver
• 200 ms with FGLRX driver

I don't think that GitHub really knew that they were slowing down their page load times by such amounts, when they started doing that with Modernizr. WebGL context creation should really only be done when you have a definite use for WebGL.

[staabm]

just an idea which came in my mind when i read this issue. maybe the testsuite should provide some sort of benchmark which measures the time which each test consumes. this could give you some further hints if some other tests also slow down the page loading process

[paulirish]

We do not ship a minified version of the library as to not recommend people using ALL tests.

Therefore you must create a custom build which only includes the webgl detect if necessary.

Part of the justification for this decision is exactly this context creation issue you describe.

So.. This is the best we can do, I think. Unless you have any other ideas..

benoit, thx for the timings. didn't have such figures. also, big fan.

@staabm I'd love that. If you're willing to contribute we can get that worked in somehow.

[staabm]

@paulirish i will give it a try on the weekend

[bjacob]

Well, again, at least 2 mainstream websites are creating WebGL contexts on page load, through their usage of Modernizr, so I suspect the issue is widespread, even if it's only a documentation / communication issue.

But I guess I'll just try to delay OpenGL context creation until the first actual WebGL call is made, so that unused WebGL contexts don't cost so much.

[bjacob]

https://bugzilla.mozilla.org/show_bug.cgi?id=732441

[bjacob]

This pages times how long it takes: http://people.mozilla.org/~bjacob/webgl.html

I now seem to get much better times than when I last tried.

[paulirish]

benoit, in that test page i would recommend 1) not adding the canvas to the DOM and 2) getting your first timing before you create the canvas element. At least, that'd better match what we're trying to address with the issue.

[staabm]

@paulirish i had a look into the testsuite but was not able to find the right place where such a "benmark-timer" could be added.

[staabm]

@bjacob

got the following error on your example page with FF11
http://people.mozilla.org/~bjacob/webgl.html

got exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMHTMLCanvasElement.getContext]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: http://people.mozilla.org/~bjacob/webgl.html :: start :: line 15" data: no]

[bjacob]

Paul, i was trying to measure specifically the cost of creating the WebGL context itself, but I understand that timing the canvas creation too could be useful.

@staabm That would mean that WebGL is not available on your system? about:support should tell you more.

[reuben]

By the way, this problem gets much worse on dual GPU MacBooks: if you're using the integrated GPU when you create the canvas, WebGL context creation needs to activate discrete graphics mode and takes around 1 second. (Imagine browsing GitHub and having that pause on every page load).

[bjacob]

Excellent point Reuben. For Firefox, that's true as of Firefox 13 / Nightly from a few days ago,
https://bugzilla.mozilla.org/show_bug.cgi?id=713305

For Chromium that's been true a bit longer, at least for the past 2-3 weeks.

Explanation: on dual-GPU macs, it is 'officially' (word from Apple) a security issue, with current drivers, to let WebGL contexts switch GPUs during their lifetime, so we have no choice but to switch and force stay on the discrete GPU before creating a WebGL context.

[staabm]

@bjacob after updating video drivers it works without this exception. thx

[paulirish]

@bjacob i just swapped in the softer detect with no context creation.

Will WebGLRenderingContext will be present with blacklisted GPUs in FF?

[bjacob]

Yes, it's present regardless of blacklisting. It will only be absent if WebGL has been completely disabled at build-time, but that is never the case in official Mozilla builds.

[paulirish]

Thx Benoit! Appreciate your help here.

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=736232 so you guys can remove the global if the GPU is blacklisted.