- From: Kenneth Russell <kbr@google.com>
- Date: Wed, 13 Apr 2011 13:21:50 -0700
On Tue, Apr 12, 2011 at 4:32 PM, Glenn Maynard <glenn at zewt.org> wrote: > Based on some discussion[1], it looks like a clean way to handle the > "permanent failure" case is: If the GPU is blacklisted, or any other > permanent error occurs, treat "webgl" as an unsupported context. ?This means > instead of WebGL's context creation algorithm executing and returning null, > it would never be run at all; instead, step 2 of getContext[2] would return > null. > > For transient errors, eg. too many open contexts, return a WebGL context in > the "lost" state as Kenneth described. > > It was mentioned that the GPU blacklist can change as the browser runs. > That's supported with this method, since whether a context type is > "supported" or not can change over time. > > Are there any cases where this wouldn't work? > > (I'm not sure if or how webglcontextcreationerror fits in this. ?It would > either go away entirely, or be wedged between steps 1 and 2 of getContext; I > don't know how WebGL would specify that.) Thanks for the pointer to the IRC logs. It looks like it was a useful discussion. It's essential to be able to report more detail about why context creation failed. We have already received a lot of feedback from users and developers of popular projects like Google Body that doing so will reduce end user frustration and provide them a path toward getting the content to work. At a minimum, we need to either continue to allow the generation of webglcontextcreationerror at some point during the getContext() call, throw an exception from getContext() in this case, or do something else. Do you have a suggestion on which way to proceed? -Ken > [1] http://krijnhoetmer.nl/irc-logs/whatwg/20110413#l-77 > [2] > http://dev.w3.org/html5/spec/the-canvas-element.html#dom-canvas-getcontext > > -- > Glenn Maynard >
Received on Wednesday, 13 April 2011 13:21:50 UTC