On 2011-04-27 17:10, Glenn Maynard wrote:
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).
On Wed, Apr 27, 2011 at 7:11 AM, Tim
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.
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.
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
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
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.
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.
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 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.