W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2011

[whatwg] Canvas.getContext error handling

From: Glenn Maynard <glenn@zewt.org>
Date: Thu, 14 Apr 2011 00:33:18 -0400
Message-ID: <BANLkTikMN-0TREAWsL3ROMP=XY3xzMAEAA@mail.gmail.com>
On Wed, Apr 13, 2011 at 9:01 PM, Kenneth Russell <kbr at google.com>
wrote:Return a new object for contextId
> Adding support for asynchronous initialization of WebGL is a good
> idea, and should be proposed on public_webgl, but this discussion
> should focus solely on improving the specification of the existing
> synchronous initialization path, and its error conditions.

I only brought it up here because they're related.  If an async path exists,
it can affect the design of the sync path as well.

> Given that the proposed asynchronous initialization path above uses
> webglcontextcreationerror and provides a status message, I think that
> should continue to be the error reporting mechanism for the current
> initialization path.

So, the main difference from how it is now would be that getContext would
return an object, even on fatal errors, since WebGL can't return null from
context creation.  That seems to work, and it does minimize the number of
things that would need to change for async initialization.  It doesn't
distinguish between "permanent" and "recoverable" errors as we discussed
earlier, but that might just be overcomplicating things.  (If that's wanted
too, it could be supported by treating preventDefault on the error event the
same as on the lost event, saying "if it becomes possible to create a
context later, I'm prepared for it".

User code for this is very simple:

var gl = canvas.getContext("webgl");
if (!gl) {
    // WebGL is not supported
} else if (gl.isContextLost()) {
     // WebGL could not be initialized; the error message can be received
from
    // webglcontextcreationerror (or webglcontextlost)
}

On Wed, Apr 13, 2011 at 10:53 PM, Cedric Vivier <cedricv at neonux.com> wrote:
> I don't think the added complexity/verbosity provides any advantage
> over my proposal above (for the applications that even desire to show
> additional failure information).
> Is there a scenario I overlooked?

Another advantage of using webglcontextlost is that, if the context
restoration proposal in the other thread is accepted, you could
preventDefault during it, just as with any other time the event is
received.  It would tell the browser "if it ever becomes possible to create
the context in the future, give it to me" (via webglcontextrestored).  You
could do that with *creationerror as well, but it would be duplicate logic.

-- 
Glenn Maynard
Received on Wednesday, 13 April 2011 21:33:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:03 GMT