[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 9:22 PM, Gregg Tavares (wrk) <email@example.com>
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.