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

Re: [Public WebGL] webglcontextrestored, WEBKIT_lose_context

On Tue, Apr 12, 2011 at 6:27 PM, Glenn Maynard <glenn@zewt.org> wrote:
> On Tue, Apr 12, 2011 at 9:22 PM, Gregg Tavares (wrk) <gman@google.com>
> wrote:
>> The problem is the application HAS TO TAKE ACTION if the context is lost
>> and restored. So, if an webgl auto-restores the context and the app doesn't
>> handle it the results are random and unpredictable. All resources are lost
>> and you have to re-create them. If the app is creating resources on the fly
>> some will get re-created some not. It was deemed that unpredictability is
>> bad. Adding a listener to "webglcontextlost" is a signal to WebGL that "this
>> app is going to handle lost/restored context". Any app that doesn't handle
>> it should fail immediately on context lost which is why it's not
>> auto-restored.
> I understand that, but this is the wrong way of indicating that you intend
> to handle a recovered context.  It violates the basic design of DOM Events.
> The method I proposed *also* *explicitly* indicates that it intends to
> handle context restoration, but in a manner compatible with the design of
> DOM Events.

Thanks for pointing out this issue and for the suggested fix. It seems
like a reasonable change, and in fact one that would be forward
compatible; if web pages are updated now, they will continue to work
up to and through the point where browsers implement the new context
lost and recovery semantics.

Could some of the other browser vendors in particular comment on this
proposed change?


You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl