[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 6:45 AM, Tim Johansson <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.

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

It would be easier to do if getContext was modified to make step 2 ("If contextId is not the name of a context supported by the user agent...") an explicit algorithm, eg. "Determine if contextId is supported by the user agent for canvas. If false, return null and abort these steps." (That's in HTML5, so we'd need to convince Ian Hickson to make the change.) That would give WebGL a clear spec entry point with a reference to the canvas, so it could say "When the user agent is required to determine if webgl is supported by the user agent for canvas, ...". It now has an explicit canvas to report errors with (whether using an event or other means), while still causing step 2 to return null.

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.

Being able to supply an error message to the calling application when context creation fails was given as a requirement earlier in the discussion. I'll defer to Ken and others about that.

--
Glenn Maynard