[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Re: [whatwg] Canvas.getContext error handling
On Thu, Apr 28, 2011 at 12:01 PM, Tim Johansson <email@example.com>
On 4/28/11 5:36 PM, Glenn Maynard wrote:
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.
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.
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.