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

Re: [Public WebGL] Lost Context

On Sat, Feb 13, 2010 at 6:30 PM, Vladimir Vukicevic <vladimir@mozilla.com> wrote:
On 2/13/2010 5:03 PM, Gregg Tavares wrote:

On Sat, Feb 13, 2010 at 3:57 PM, Vladimir Vukicevic <vladimir@mozilla.com> wrote:
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.

I don't quite follow how that would work. By "handle" even do mean by returning something or setting something on the event object?

Maybe some sample code would help.

Basically something like context.reset(), but on the event itself: something like event.resetContext() to ensure that it can't/shouldn't be called normally unless you actually have the event that you're responding to.  content.reset() is probably fine also though, it can just be an error to call it if there's no outstanding context lost event.

... then again, now that I think about it, if the semantics of reset() are that you get a brand new GL context with all state and resources invalidated, I don't see why allowing it to be called arbitrarily would hurt, so maybe we should do that?  I realize that this is basically your original proposal now :)

I'd like to suggest one more thing.  That context.reset() return true or false if the context was actually reset.

Here's the thinking.

Imagine you have 1 tab open running SuperQuake WebGL and it uses 60% of the resources. Now imagine you open a second tab and run SuperShooter WebGL that also needs 60% of the resources.  When an implementation sees that there are no more resources it could send lost-context to all apps. Each app will then call context.reset(). Returning true/false lets the implementation choose which app gets the resources. In this case SuperShooter is the front tab so its call to context.reset() will succeed and return true.  SuperQuake's call will fail and return false. SuperQuake can call it again later until it succeeds (it's tab is put in front).


    - Vlad