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

Re: [Public WebGL] Help with the WebGL Context Lost specification

On Wed, Dec 14, 2011 at 9:07 AM, Glenn Maynard <glenn@zewt.org> wrote:
(Another gigantic email...)

On Wed, Dec 14, 2011 at 11:54 AM, Benoit Jacob <bjacob@mozilla.com> wrote:
The current spec says (IIUC) that the first WebGL call, and only the first call, following a context loss, should generate an WEBGL_CONTEXT_LOST error.

All it says is:
GLenum getError() (OpenGL ES 2.0 §2.5, man page)
If the context's webgl context lost flag is set, returns CONTEXT_LOST_WEBGL the first time this method is called. Afterward, returns NO_ERROR until the context has been restored.
The ED puts it differently, but has the same effect.
So IIUC it requires the implementation to keep track of whether a WebGL call was already made since the context loss.

It only requires keeping track of whether getError has been called.  Calling most functions while the context is lost is a complete no-op: steps 1.2 of [1] returns without doing anything.

[1] https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/specs/latest/index-context-lost.html#5.14 @ r16355

It doesn't require any of the that. Most implementations either have a set of error flags or a last error. When context lost is detected, in the error flags case you do this

   error_flags = CONTEXT_LOST_WEBGL_BIT;

which effectively clears all the bits except 1. In the last error case you do

   last_error = CONTEXT_LOST_WEBGL

After that since every function is a no-op, and since getError always clears the error or the bit for a specific error you'll only get one CONTEXT_LOST_WEBGL error.  No checking needed

Maybe you want want to change the spec to make that clearer?

As for bugs in the context lost conformance test Douglas is correct, it's a bug. At the time I fixed the test there was no spec compliant WEBGL_lose_context extension so there was no way to test it. The line mentioned 
    shouldGenerateGLError(gl, gl.NO_ERROR, "extension.loseContext()");

should be changed to


Similarly, most likely, any other calls to extension. should not be wrapped in a shouldGenerateGLError

That's just an oversight from copying and pasting lines and not having the ability to test.

Glenn Maynard