On Thu, Apr 28, 2011 at 6:45 AM, Tim Johansson <email@example.com>
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
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
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
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.