[Public WebGL] How to check for WebGL support
Thu May 19 11:10:59 PDT 2011
On Thu, May 19, 2011 at 10:59 AM, Benoit Jacob <[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
> 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.
> 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.
> In any case, in order to get a 100% reliable answer, there is no way around
> creating an OpenGL context. Indeed, even if the setup is not explicitly
> blacklisted, there could be a problem with it that we only detect when
> creating an OpenGL context, and also a WebGL implementation may require the
> OpenGL implementation to meet certain requirements that can only be checked
> from an OpenGL context, say with glGetIntegerv.
> So, for a 100% reliable answer, calling getContext() isn't much costlier
> than is necessary. If one wanted your proposal to be 100% reliable, it would
> have to do essentially the same at startup, as (as far as I know?) the
> WebGLRenderingContext interface would have to be defined at startup to
> ensure that it's defined before scripts start checking for its existence
> (correct me if I'm wrong here?).
> Another disadvantage is that in the common case where the user only uses
> one WebGL context during his browsing session, one would now be creating 2
> WebGL contexts instead of 1.
> If a less-than-100% reliable answer is enough, so that we don't need to
> create a OpenGL context, I'm still afraid of having to check the WebGL
> blacklist on startup before knowing whether it's going to be used.
I would settle for a less-than-100% solution that's quick. I know that at
least in Chrome we do the blacklist checks on startup so it wouldn't affect
performance. I would imagine that any h/w accelerated browser these days
would have to check its gpu blacklist very early on, not just for WebGL.
Do we really have many cases where h/w isn't blacklisted but still fails
context creation due to lack of specific capabilities. And if so maybe
these cases need to be identified and put in the blacklist.
The point is that if I only want to know whether WebGL is supported on the
system (say I want to know whether to display a link to the 3D version of my
product or not) then creating a context and subsequently deleting it is a
very heavy handed approach.
> I do agree with the need to offer better information about WebGL context
> creation failure, either via an exception or via webglcontextcreation error,
> what I don't know is if there can be any better API to detect WebGL
> availability than just calling getContext().
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the public_webgl