[Public WebGL] WebGL spec needs clarification around extensions and context lost / restored events
Thu Jun 6 15:09:08 PDT 2013
On Tue, Jun 4, 2013 at 9:06 PM, Gregg Tavares <[email protected]> wrote:
> It seems like the current spec has an issue around extensions and context
> 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
This sounds good. When the context is lost, extensions should not only
be marked lost, but the extension objects themselves should be
permanently disassociated from the WebGLRenderingContext. When the
context is restored, getExtension(extensionName) should return a new
extension object. WEBGL_lose_context should be the only exception to
this rule; it should never be lost. I think for simplicity it probably
should not be disassociated from the context either when the context
is lost; what do you think?
> 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
Agreed that something needs to change when the WebGLRenderingContext
constructor is added. It looks like the easiest solution may be to say
that the drawing buffer is 0x0. Otherwise another flag (like the webgl
context lost flag) will be needed and some of the steps during context
restoration will have to be skipped.
> 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
Right. WebGLRenderingContext needs to be an EventTarget to receive
context lost events in this situation.
I think we should first fix up the context lost language for
extensions, and then move on to adding the constructor, since that
will require more extensive spec changes.
You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
More information about the public_webgl