[whatwg] Challenging canvas.supportsContext
jacob.benoit.1 at gmail.com
Wed Jun 19 16:22:20 PDT 2013
2013/6/19 Kenneth Russell <kbr at google.com>
> In my experience, in Chromium, creation of the underlying OpenGL
> context for a WebGLRenderingContext almost never fails in isolation.
> Instead, more general failures happen such as the GPU process failing
> to boot, or creation of all OpenGL contexts (including the
> compositor's) failing. These failures would be detected before the app
> calls supportsContext('webgl'). For this reason I believe
> supportsContext's answer can be highly accurate in almost every
In Mozilla code, we fail WebGL context creation if any GL error occurs
during initialization, where we have to make a number of specific OpenGL
calls (e.g. querying many constants, enabling point sprites...). So it is
perfectly possible for WebGL specifically to fail on a given device where
OpenGL compositing works, without being specifically blacklisted, and
currently we can rely on these automatic checks rather than having to
curate a blacklist for these problems, which is very nice.
Another way in which WebGL specifically can fail, is that some driver bugs
cause errors that we may want to ignore in our compositor code but not in
WebGL. To give an example, on many Vivante GPU drivers, which are very
common in Chinese mobile devices, the first eglMakeCurrent call on a newly
created context can return false without any actual EGL error . A
browser may want to ignore this error in its compositor to be able to run
nonetheless on such devices, but without WebGL support.
To summarize, blacklisting is not the only reason why WebGL specifically
may fail, and this is particularly concrete on low-end mobile devices.
Checking whether any WebGL context creation succeeded in the current
browser session is a very useful data point indeed, but doesn't help with
the _first_ context creation (which seems particularly relevant for the
Chrome Web Store use case mentioned earlier).
More information about the whatwg