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

Re: [Public WebGL] Comments on Dec 20th draft

On Wed, Dec 21, 2011 at 2:41 PM, Glenn Maynard <glenn@zewt.org> wrote:
> On Wed, Dec 21, 2011 at 12:07 PM, Daniel Koch <daniel@transgaming.com>
> wrote:
>> Desktop GL with the ARB_robustness extension and reset notifications
>> enabled can result in a lost context.   Unfortunately that extension doesn't
>> specify what happens if you make GL calls when the extension is lost.
> That extension appears to effectively say that you're supposed to constantly
> check GetGraphicsResetStatusARB() before every OpenGL call ("After a reset
> event, apps should not use a context for any purpose other than determining
> its reset status, and then destroying it."), which doesn't seem like a very
> usable API.  Also, saying that users shouldn't do something, without
> defining what happens if they do, seems like a bug.
> What happens if the context is lost between a call to
> GetGraphicsResetStatusARB() and an OpenGL call immediately after it?  That
> seems like a race condition that makes it impossible to actually avoid using
> a context that's been lost.

The API works well enough despite its inevitably asynchronous nature.
Chromium checks for loss of context periodically, including after each
draw call -- however, this still doesn't guarantee immediate detection
because of buffering in the GL implementation.

Regardless, if context loss is detected, the WebGLRenderingContext is
notified and a webglcontextlost event at the next available
opportunity. The expectation is that if the context is lost
spontaneously between two arbitrary GL calls, that subsequent GL calls
will essentially be no-ops.

Daniel has raised the issue of ambiguity in the ARB_robustness spec in
another forum. The WebGL mailing list is not the best place to discuss
these concerns.


>> We've implemented an ES version of this extension in ANGLE
>> (EXT_robustness) and we generate GL_OUT_OF_MEMORY on all GL calls that
>> happen after a lost context.  We'd considered making all the calls NOPs as
>> suggested above, but any GL call that has a return parameter will have
>> un-defined contents and that is only allowable by the spec if you have an
>> OOM error.
> Context loss shouldn't result in undefined output, it should leave the value
> unchanged.  Causing undefined changes to be made to these parameters would
> be very difficult to code for; you'd have to check getError() after each
> such call, which isn't normal (more, it's discouraged) in OpenGL programs.
> Is there something about the Direct3D implementation that makes this hard to
> do?

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl