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

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

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.

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.

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