[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Wed, Apr 27, 2011 at 7:11 AM, Tim Johansson <timj@opera.com> wrote:
For creating context when the context is lost it sounds OK, but I don't really understand why we would want to return a valid context that will never work when the GPU is blacklisted. If the GPU is blacklisted or missing features WebGL is IMO not supported on that device, and if webgl is not supported getContext should return null. That is all according to the spec as far as I can tell.

WebGL isn't quite defining context creation properly.  It defines the getContext call itself, which isn't part of WebGL; it's specified by HTML5.  Context APIs (WebGL and 2d canvas) just specify the "Return a new object for contextId" algorithm, which getContext refers to in step 6.  That algorithm can't return null--it can only return an object.

Handling errors by treating them as "contextId is not the name of a context supported by the user agent" (getContext step 2) was discussed.  In principle the error event could be wedged in there ("when WebGL is required to determine if "webgl" is a context supported by the user agent for a given canvas, run the following steps...").  That's odd, though, and assumes that a canvas object is always around when "is the name of a context supported" happens, which isn't necessarily true.

I think consolidating error reporting and consistently supporting recoverable errors is a win.  If you have time, please also check the thread on async context creation, which also ties in well with this.

Should we also return a valid context when trying to create a context on a device where there is no capable graphics chip, for example on a mobile only supporting OpenGL ES 1.1? What about if there is a setting to disable webgl, should we still return a context then?

I think it's ultimately up to the browser.  If it doesn't want to return an error message for some unrecoverable errors, it can always opt to return null and pretend WebGL isn't implemented at all.  This would still be allowed because of step 2 of getContext: the UA can treat "webgl" as not a supported contextId, in which case it returns null before the WebGL is even invoked.

If there's a setting to disable WebGL, that can be recoverable, since the user can change the setting.  If the user reenables WebGL in his settings, pages would see a context restoration event and begin working immediately, instead of the user having to refresh the page or take some other action.  This would be consistent whether getContext failed initially (WebGL was turned off when the page was loaded) or whether the context was lost later (the user disabled WebGL while the page was already loaded).

I am also not sure how this would work with switchable graphics. If only one of the GPUs are capable of running webgl and that is active when creating the context you might get an unrecoverable error (unless you can find out that there are two GPUs and the other will work). But if the other context is capable and the user switches to that you could possibly restore the context. Should we always assume non-recoverable errors if we are not sure it is recoverable, or always assume recoverable if we are not sure it is non-recoverable?

I don't think it's either extreme.  It's always possible that a recoverable error might never recover in a particular situation, and there can be vanishingly rare cases where "fatal" errors might actually be recoverable (a browser's GPU blacklist being updated dynamically, unblacklisting the user's hardware).  It's ultimately a judgement call for implementations, I think.  The only requirement I think should be in the spec is that nonrecoverable errors are guaranteed to not recover.

Maybe "fatal" is a clearer name than "recoverable".  "!event.fatal" doesn't guarantee recoverability, "event.fatal" just guarantees unrecoverability.

[1] http://dev.w3.org/html5/spec/the-canvas-element.html#dom-canvas-getcontext

Glenn Maynard