[Public WebGL] How to check for WebGL support

Benoit Jacob [email protected]
Thu May 19 11:37:27 PDT 2011


----- Original Message -----





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


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. 


Thoughts? 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. That's true, but even so, each blacklist lookup has a cost, and I think we're all equally paranoid about startup performance ;-) 

I guess my main concern here is that it's not really needed to make that a startup cost. Why not instead offer a isWebGLAvailable() function that would do the work when it's first called? 







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. Currently we have quite a few cases, for example Intel 945 in Ubuntu 11.04 doesn't have OpenGL 2, and we don't have an explicit blacklist entry for that, we currently rely on context creation to fail. 

We don't currently require any particular OpenGL parameter for WebGL, but I find it conceivable that an implementation would. For example, an implementation could decide to require DEPTH_STENCIL renderbuffers, or it could require the presence of certain texture formats, etc. 

I agree that any of that could be added to the blacklist. It's just that it's nice not having to add more blacklist entries, when we could instead check the actual OpenGL parameters. 

Benoit 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20110519/86effb46/attachment.html>


More information about the public_webgl mailing list