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

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



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