[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: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.

The opposite way makes no sense. Apps that don't deal with lost-restored contexts are not going to start correctly marking themselves as unable to handle the situation. Rather, only apps that go to the effort to handle lost-restored contexts will tell WebGL they know how to handle it.

The default behavior with this proposal is that a lost context is permanent (since on a context loss without a webgllostcontext event handler the default action will occur and the context will be marked as permanently lost).  The application has to opt-in to auto-restoring the context by registering a contextlost event handler that calls event.preventDefault().

- James