[Public WebGL] How to check for WebGL support

Benoit Jacob [email protected]
Thu May 19 11:13:03 PDT 2011



----- Original Message -----
> 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.

I don't see any other solution to this problem than blacklists (unless perhaps one would go to the extreme of running WebGL in a separate process).

The idea of defining WebGLRenderingContext only if it's not blacklisted, does not seem to offer any more protection: if the system is blacklisted, then getContext doesn't cause problems anyway.

Benoit

> 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.
> 
> -Ken
> 
> -----------------------------------------------------------
> 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
> -----------------------------------------------------------

-----------------------------------------------------------
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