[Public WebGL] How to check for WebGL support

Kenneth Russell [email protected]
Thu May 19 10:57:41 PDT 2011

On Thu, May 19, 2011 at 10:37 AM, Vangelis Kokkevis <[email protected]> wrote:
> A recurring issue with sites that want to use WebGL is that there's
> currently no good light-weight way to check whether WebGL is supported in a
> particular client. We have a couple of mechanisms in place but they all have
> drawbacks:
> 1. Statically check for window.WebGLRenderingContext :  This will return
> false positives, e.g. when running on blacklisted configurations, when WebGL
> is explicitly disabled via some user pref, etc.
> 2. Create a WebGL context and inspect the result : Creating a context is
> expensive (slow) and when you only need to know whether WebGL is supported
> the resulting context isn't really needed.

In my opinion the problem with creating a context is not really that
doing so is expensive; there have been other discussions recently
about making WebGL context creation asynchronous, and the conclusion
so far was that it's fast enough to not warrant the spec change right
now. The main issue is that implementations are still not robust
enough to ensure that creating a context won't cause problems. For
example, there was a bug in Chrome a couple of releases ago where if
WebGL context creation failed, the page would freeze.

> One possible solution would be to define window.WebGLRenderingContext only
> if both the browser supports WebGL and all the blacklist / user-pref / etc.
>  tests succeed.  Current pages will have to be tweaked to report a more
> generic "WebGL is not supported on your configuration" type of message
> rather than "Your browser does not support WebGL".  If they really need to
> know why it's not supported they can go one step further and try to create
> the WebGL context and decipher any context creation error.
> Obviously there will still be some false positives with this mechanism but
> they will hopefully be rare.

I'd like to point out that Chrome used to behave in this way, but the
behavior was deliberately changed based on feedback from Mark Callow;
see http://crbug.com/77110 . I don't have a strong opinion about
whether to revert to the earlier behavior and formally specify it.


You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl

More information about the public_webgl mailing list