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

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




On 2011-04-22 00:56, Kenneth Russell wrote:
On Tue, Apr 19, 2011 at 7:35 PM, Cedric Vivier<cvivier@mozilla.com> wrote:
On Wed, Apr 20, 2011 at 10:20, Mark Callow<callow_mark@hicorp.co.jp> wrote:
On 19/04/2011 04:06, Glenn Maynard wrote:
Following up from whatwg:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031192.html.
To recap, step 6 of getContext ("Return a new object for contextId"),
which is where WebGL takes over, was never intended to return null.
null isn't a "new object", it's no object.
What happens if the context type passed to getContext is not recognized
by the browser, e.g., when WebGL is not supported by the browser?
Null is returned, as specified in the Canvas spec.

If we go this route, a status message in webglcontextlost is
insufficient. Applications that wish to handle webglcontextlost will not
want to be parsing strings, especially localized strings, to determine
if the browser is refusing to create a context, so there is no
possibility of restoration, or if it is a normal context lost event.
Some kind of error code will be needed.
Yes, I believe adding an isRestorable boolean to the webglcontextlost
event would help to differentiate between a permanent or transient
error.

statusMessage should be used for display only and should never have to
be parsed.
To make sure it does not get abused *and* to let browsers give better
diagnostic to users, we might even want to get rid of it, if the
browser actually has useful failure information to provide, it could
expose it in a more useful/consistent way to the user directly.
I wonder whether it would be an improvement if Canvas's getContext()
algorithm admitted the possibility of an exception being thrown during
context creation. As it stands, every new context type which has the
possibility of failing to initialize has to define its own,
callback-based, error reporting mechanism. Maybe this isn't that big a
deal, because these context types might have to deal with "lost"
contexts like WebGL does.

This comment aside, the semantic change to return a non-null context
when an error condition occurs sounds acceptable to me. I'm not
completely happy with it, because I think that it will make error
detection harder for the developer. I think we should gather more
feedback, in particular from other browser vendors on the working
group, before committing to make this change. Note that existing WebGL
content is going to have to be updated to deal with this change, in
order to continue to properly detect the situation when the graphics
card is blacklisted.


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.
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 am also not sure how this would work with switchable graphics. If only one of the GPUs are capable of running webgl and that is active when creating the context you might get an unrecoverable error (unless you can find out that there are two GPUs and the other will work). But if the other context is capable and the user switches to that you could possibly restore the context. Should we always assume non-recoverable errors if we are not sure it is recoverable, or always assume recoverable if we are not sure it is non-recoverable?

//Tim

If we proceed with this change, I agree that we need an indication
that the failure was not recoverable, so that the application can
display appropriate UI to the end user. Adding a boolean to the
webglcontextlost event seems somewhat like a hack, because it
essentially changes the meaning of the event to exactly that of
webglcontextcreationerror. Does anyone have an alternative idea?
Subclassing the event type? Continuing to use a different kind of
event listener? If there's no better suggestion then it sounds okay.

Additionally, if we proceed with this change, I do not support the
removal of the statusMessage. As an implementor of WebGL, I require
the ability to provide some information to application developers
(which might end up being sent back in in bug reports) when for some
reason WebGL could not initialize.

-Ken
-----------------------------------------------------------
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
-----------------------------------------------------------

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