[whatwg] Canvas.getContext error handling

I forgot that this was all still going to whatwg, instead of public-webgl.
We may want to move there.


On Thu, Apr 14, 2011 at 12:33 AM, Glenn Maynard <glenn at zewt.org> wrote:

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


-- 
Glenn Maynard

Received on Thursday, 14 April 2011 07:22:26 UTC