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

Re: [Public WebGL] Lost Context



On 2/13/2010 1:23 PM, Gregg Tavares wrote:


On Sat, Feb 13, 2010 at 11:04 AM, Vladimir Vukicevic <vladimir@mozilla.com> wrote:
On 2/12/2010 10:10 PM, Gregg Tavares wrote:

Removing the "resource" argument, and that if you get one of these events the context in question is no longer valid. Every call to anything in that context from that point on will have no effect and context.getError will constantly return context.LOST_CONTEXT

To recover you have to create a new context by calling canvas.getContext("webgl")

I like this suggestion, but there's a problem with the recovery mechanism -- you can't just call getContext again, because getContext is specified to give you back the same context object for any previous call for "webgl"; and that context is no longer valid.

So, perhaps this event should be called a Context Reset event, where you lose all resources/state, but the WebGL implementation ensures that the same context object is valid again?

That's one idea but wouldn't solve the issue mentioned before that if you get the event halfway through that loop, half of your resources are okay and half are not.  From the example above,

ctx.bindTexture(ctx.TEXTURE_2D, textures[2]);  // would fail
ctx.bindTexture(ctx.TEXTURE_2D, textures[52]);  // would not fail

It seems like it would be good if everything fails after a context lost event until you are ready to deal with it.

Another solution is you could get Context Lost and everything fails until you call context.reset() 

Or a reset/acknowledge method on the event?  Context becomes bad until the event is explicitly handled; if it's not, it remains bad/everything fails.

The issue is also that the implementation has to track which resources are good and which are bad. Since each resource is already associated with a context it seems easier to just say that lost context is bad and you need a new context. We could change the spec so calling canvas.getContext("webgl") does not return the same context if you've lost the context.  Then if you tried to use a resources from the original context with the new context it would be obvious why it's failing.

All resources would be bad, no?  That is, no current resource handles would be valid (internally, each resource would be associated with not just a context, but a context and a serial number/age).

newContext.bindTexture(gl.TEXTURE_2D, oldTexture);  // EXCEPTION object not from this context?

On the other hand, the context.reset() way could just as easily hide the fact that underneath it's creating a new actually GL context and that all your old resources, being associated with the old context, are invalid. I guess the new context seems cleaner to me but either way works.

I'll bring up another issue which I'm sure no one wants to discuss but, passing all this lost context stuff down to _javascript_ sure seems far removed from anything else in HTML. Imagine if <img>, <video>, <audio>, <canvas2d> etc all needed _javascript_ to manually deal with lost-context.

Yep, it's not that we don't want to discuss it, it's more that there's really no sane way around it -- the only alternative is to keep a copy of every user resource.  It would be better if the underlying GL/D3D impl would take care of all of that, and I'd guess that we'll get there eventually..

    - Vlad