[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 <firstname.lastname@example.org>
On 2/13/2010 5:03 PM, Gregg Tavares wrote:
On Sat, Feb 13, 2010 at 3:57 PM, Vladimir
On 2/13/2010 1:23 PM, Gregg Tavares wrote:
On Sat, Feb 13, 2010 at 11:04 AM,
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.
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
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); // would fail
ctx.bindTexture(ctx.TEXTURE_2D, textures); // 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
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
... 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).