[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Re: [whatwg] Canvas.getContext error handling
On Thu, Apr 21, 2011 at 6:56 PM, Kenneth Russell <email@example.com>
algorithm admitted the possibility of an exception being thrown during
I wonder whether it would be an improvement if Canvas's getContext()
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.
That's what I thought originally. I talked to Ian Hickson about this, and his take was that getContext should never fail; it should either give a usable context or not. This way is more consistent when combined with recoverable errors (eg. lost contexts) anyway.
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.
It's not quite harder, but it's a bit easier to miss: if you don't set up an error handler then you can end up just drawing on a lost context and not showing any error message. Unless the definition of getContext is changed to support errors, I think that's inherent--and of course, you *should* be setting up an error handler. Note that this problem wouldn't exist with an async path. I'll open a separate discussion about that now, since it's come up several times.
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.
I thought about this, but left it out of the summary to simplify a bit. It can either be a "recoverable" property on the event, or by sending separate events, eg. "webglcontextlost" and "webglcontexterror", which are exactly identical, except the former is used for recoverable errors and the latter isn't cancelable (preventDefault does nothing, since it can't recover anyway).
I prefer a "recoverable" event property. It's simpler, the two cases are very similar, and users will often do the same thing in both cases. Also, the "context fatally lost after the context was successfully created" (eg. the GPU blacklist was updated and the WebGL context was permanently revoked) case is very rare. I suspect handling them with the same message will improve the odds of scripts handling this case reasonably.
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.
My suggestion was to include the statusMessage within webglcontextlost.