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

[Public WebGL] Re: [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@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