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

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




On 4/28/11 5:36 PM, Glenn Maynard wrote:
On Thu, Apr 28, 2011 at 6:45 AM, Tim Johansson <timj@opera.com <mailto:timj@opera.com>> wrote:

    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.


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

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.


It seems hard to get both this and the ability to return an error message to the application, unless HTML5's getContext spec is changed or it's wedged in as I described earlier (ugly).


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.

//Tim

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------