[Public WebGL] WebGL spec needs clarification around extensions and context lost / restored events

Gregg Tavares [email protected]
Tue Jun 4 21:06:15 PDT 2013


It seems like the current spec has an issue around extensions and context
lost

Section 5.14 says every method on every extension must check if the context
is lost. If so use the default return value.

Unfortunately that seems insufficient. When the context is lost the
extensions are lost as well. Getting the context restored does not mean the
same extensions will be available. For example, plug 2 GPUs into a Windows
7 or 8 machine. In the control panel disable one of the 2 GPUs. Get a WebGL
context. Re-enable the disabled GPU and disable the other. A WebGL
implementation will be required to lose the context, when it creates a new
one it will be on another GPU with different capabilities which means that
extensions that may have existed before no longer exist.

It seems like the spec should probably say that when the context is lost
all extensions are also lost.  (section 5.15.2, Step 4.5: Set the 'lost'
flag on each WebGLExtension instance created by this context) Lost
extensions follow the rules in 5.14 but instead check their own 'lost' flag
and unlike a contexts, lost extensions can never be restored. Instead you
must get new extensions from the restored context.

That means the docs for getExtension (5.14.14) also need to change to say
the object you get from getExtension is the same only as long has the
context has not been lost.

On top of that it needs to be made clear that the WEBGL_lose_context
extension is special in that it is never lost (otherwise you couldn't call
restoreContext)

Thoughts?

A couple of other complications

1) the steps for context lost and context restored talk about things like
'queue a task to restore the drawing buffer' for the context. But if we're
going to allow creating WebGLRenderingContexts directly from the
constructor then that language doesn't make a lot of sense since they won't
by default have DrawingBuffer (or maybe the spec could say they have a 0x0
DrawingBuffer?)

2) while we're here there's also the issue that WebGLRenderingContext
created directly from the constructor needs a way to handle context lost
and context restored that is associated with the context, not the canvas as
they have no canvas. note: The same potentially holds true for directly
created CanvasRenderingContext2D instances

-g
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20130604/e345d8f8/attachment.html>


More information about the public_webgl mailing list