[Public WebGL] Re: [whatwg] Canvas.getContext error handling

Kenneth Russell [email protected]
Thu May 5 17:00:47 PDT 2011

On Thu, Apr 28, 2011 at 9:58 AM, Glenn Maynard <[email protected]> wrote:
> On Thu, Apr 28, 2011 at 12:01 PM, Tim Johansson <[email protected]> wrote:
>> On 4/28/11 5:36 PM, Glenn Maynard wrote:
>>> Note that blacklisting is different than the device not being able to
>>> support WebGL, since device blacklists are updated on the fly in some
>>> implementations (Chrome, from what I understand) which can cause WebGL
>>> support to go away (or return) after pages are already running.
>>>  Insufficient hardware is unlikely to change at runtime.
>> In theory they are different yes, but the chances that the blacklist will
>> be updated to remove blacklisting of a gpu while you are looking at a page
>> that did not load (because the gpu was blacklisted) are so insignificant
>> that for all practical purposes they are the same thing.
>> A driver being added to the blacklist cannot affect the context creation
>> of a running app since that context has already been created so it only the
>> - probably extremely rare - "webgl returns" case that would mater. It would
>> have to signal a lost context in the case of "webgl goes away".
> Pages can create WebGL contexts at any time.  For example, you can create a
> context in a hidden canvas to perform off-screen image manipulation, which
> you pull out of the canvas by other means like canvas.toDataURL.  Long-lived
> web apps are now common; I often leave pages loaded in tabs for weeks
> without reloading them.  It's very possible for pages to attempt to create a
> WebGL context when the GPU is blacklisted, but wasn't when the page was
> originally loaded.
> (You can still say that "the contextId 'webgl' is not a supported rendering
> context" and return null from step 2, despite this.  It just means that the
> contextId would be considered unsupported despite the fact that
> WebGLRenderingContext, etc. are present in the window.  That's not a big
> deal.)
>> Yes, this all assumed that non recoverable errors would not send a message
>> but leave it up to the browser or a troubleshooting page to notify the user
>> of why the context creation failed. The app would only know that context
>> creation failed and it cannot be solved by trying again. Recoverable errors
>> could still get a status message as it would be signalled through context
>> lost.
> I suggested that earlier and it was rejected--addressing that objection was
> where this proposal originated.  My main underlying goal is just to
> reconcile WebGL with HTML5's getContext spec.

It sounds like my earlier objection may have caused an impasse. To
clarify, the reason for the objection was the following. If the GPU is
blacklisted, or some rare and unexpected error happens during OpenGL
context creation, then it is important to be able to communicate that
fact clearly to the developer, and from there to the end user. If the
WebGL implementation can only return null in these situations, with no
other channel for reporting programmatically what happened, I think
this will lead to frustration by end users who can't get WebGL to work
and who can't figure out why. (And further, the WebGL implementor will
not easily be able to diagnose what happened.) It's almost inevitable
that some kind of unexpected error will occur during WebGL
initialization on some hardware/driver configuration.

It might be acceptable to return null from the getContext call, report
these errors to the JS console and rely on a troubleshooting page to
point to them. I much prefer having the option to provide some error
message to the application.


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