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

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

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.

I'd recommend, in line with Cedric's suggestion:

 - getContext always returns a WebGLRenderingContext, whether the drawing surface can be created or not.
 - If the drawing surface couldn't be created (where it currently returns null), synchronously dispatch webglcontextlost before getContext returns.
 - webglcontextcreationerror is dropped; statusMessage is included with webglcontextlost instead.

This addresses the getContext API issue.  Also, all context creation errors are reported in one place (webglcontextlost), whether it's an initial failure during getContext or a failure later on.  These failures are symmetric--they can both happen for the same reasons.

The webglcontextlost event stays consistent: preventDefault would allow restoring the context later on if possible, regardless of whether the event was fired by getContext or later on.  This will help stop people from implementing ugly retry-getContext timers or "try again!" buttons; if you want to support recovery from initial context failure, just preventDefault the event as you would any other time.

(As a bonus, an async initialization API becomes straightforward.)

Sample initialization code:

var error = null;
canvas.addEventListener("webglcontextlost", function(event) { error = event.statusMessage; }, false);

var gl = canvas.getContext("webgl");
("WebGLRenderingContext" in window) == (gl != null)); // this is now guaranteed
if(gl == null)
    throw "WebGL is not supported by your browser";

// either initWebGL has already been called or error is set
if(gl.isContextLost()) // or if if(error != null)
    throw "Error initializing WebGL: " + error;
// continue initialization

On Thu, Apr 14, 2011 at 10:22 AM, Glenn Maynard <glenn@zewt.org> wrote:
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@zewt.org> wrote:
On Wed, Apr 13, 2011 at 9:01 PM, Kenneth Russell <kbr@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@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

Glenn Maynard