[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:06 PM, Glenn Maynard <glenn@zewt.org> wrote:
A problem with webglcontextrestored: "The system only restores the context if a handler for the webglcontextrestored event is installed on the HTMLCanvasElement associated with the context."

Registering DOM event listeners doesn't have side-effects.  Calling object.addEventListener("string", function(e) { }, false); should never have any perceivable side-effect.  I don't know of any API on the platform where this isn't the case.

I recommend: "The system only restores the context if the default behavior for the webglcontextlost event is prevented." (Note: webglcontextlost here, not webglcontextrestored.)

In other words, the default behavior of webglcontextlost is to prevent restoration of the context.  This is much more consistent with how DOM events work.  (I'll suggest a more precise spec wording later after some other discussions move forward, if there's interest in making this change.)  To enable context restoration,

canvas.addEventListener("webglcontextlost", function(e) { e.preventDefault(); }, false);

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.


A related issue (maybe some WebKit list is a closer fit for this, but it seems appropriate here):

WEBKIT_lose_context exposes one function: loseContext.  It causes the context to be lost, and then restored a moment later.  This allows testing context loss, but it's incomplete: it's not possible to cause the context stay lost.  This is needed to test script behavior during an extended or permanent context loss; for example, when manipulating UI controls while the context is still lost.

I'd suggest adding a "force" parameter to loseContext; if true, an internal flag is set, persistently preventing the context from being restored.  Second, add a restoreContext() method, which unset the flag, allowing the context to be restored at next appropriate time in the event loop.  If the "force" flag wasn't already set, restoreContext() triggers INVALID_OPERATION.

I think this it's important to make it as easy as possible to test context loss, or else nobody is going to handle it correctly.

Glenn Maynard