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

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

On 2011-04-27 17:10, Glenn Maynard wrote:
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.

What I meant was that for non-recoverable, permanent errors the WebGL spec could say something along the lines of "If the device is not capable of running WebGL content WebGL should be considered unsupported." That would make getContext return null in step two (without sending an event).

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.

To send an event there is odd yes, that was not what I meant we should do. You could easily check for permanent errors (such as GPU not present or blacklisted) when checking if webgl is supported. Or you could check at startup and cache the result.

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.

I really don't like unspecified behavior, 99.9% of the time that means we'll have to try to figure out what others are doing and do the same thing in order to be compatible with content on the web. I would prefer if the spec said something about what should happen when the device is not capable of supporting webgl, which would include blacklisting.

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).

Right, but generally when you disable a feature you want to get the same thing you would get if the feature was not present, which generally is to give you fallback content. If you disable _javascript_ you want to get the noscript tag, if you disable canvas you want to get the canvas fallback content etc. For WebGL the fallback could be to render using the 2d context if the webgl content is not present. It does not seem entirely unreasonable that apps would use webgl to render 2d content for performance reasons but fall back to the 2d context to be compatible with older browsers, devices with blacklisted GPUs and ie9.

I would personally rather remove the context creation error event than making a change that will complicate context creation. The permanent errors should be easy to handle by returning null without an event. For context lost on context creation (which is probably going to be very rare since it is mainly crashers, sleep and in some cases screensaver) we could potentially return a context which is lost. In order to recover it we would have to specify the contextlost event to trigger if it is set while the context is lost so you can call preventDefault and restore the context.