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

Re: [Public WebGL] Addition to WebGLContextLostEvent wrt extensions

On Thu, Apr 8, 2010 at 1:27 AM, Chris Marrin <cmarrin@apple.com> wrote:

On Apr 6, 2010, at 7:47 PM, Gregg Tavares wrote:

> On Wed, Apr 7, 2010 at 12:07 AM, Cedric Vivier <cedricv@neonux.com> wrote:
> On Tue, Apr 6, 2010 at 23:42, Gregg Tavares <gman@google.com> wrote:
> On Tue, Apr 6, 2010 at 7:03 PM, Cedric Vivier <cedricv@neonux.com> wrote:
> I don't think this is an issue at all in WebGL due to the simple single-threaded event model of _javascript_.
> Afaik contrary to C-like signals which are preemptive, once the loop is started it will have to finish before _javascript_ can handle any WebGLContextLostEvent or WebGLContextRestored event.
> If the context is lost at 120, the loop will continue and quickly generate GL errors at every subsequent call until it stops; then when the current _javascript_ chunk has been completed the registered WebGLContextLostEvent handler will be ran then the WebGLContextRestored handler, which will likely restart the whole loop again (assuming this loop is in e.g init).
> The WebGLContextLostEvent and WebGLContextRestored event may be single threaded but GL itself is not. The user can press the hibernate button at any time.  If the model is WebGL restores its self which is what WebGLContextRestored suggests that this is a real case. I can keep trying to come up with examples where the context going from bad to good without app control is bad idea.
> I was assuming it would be possible for WebGL implementations to restore the context ONLY just before the _javascript_ handler is executed (e.g an internal native event listener that resets the context when the dispatched event is actually ready for execution in the _javascript_ context).
> Afaik *if that's possible* (?) then WebGLContextRestored would have no drawbacks but only advantages (simplicity in both concept and user code implementation) compared with a WebGLContextReady+resetContext() right? (since the order of execution would be obligatory the same in both cases)
> Maybe some sample code would help me see how WebGLContextRestored would work.

Here's how I think this would all work. I'll avoid including any logic that does the work of loading or running the app for clarity:

function start() { /* starts running the main loop. Assumes everything is setup, initialized and loaded */ }

function stop() { /* stops running the main loop */ }

function initState() { /* set the app to an initial state */

function saveState() { /* saves the current state of the app */ }

function restoreState() { /* restores previously stored state. If no saved state, calls initState() */ }

function startAssetLoad(assetsToLoad, initFinishedFunc) { /* loads the passed array of assets and fires initFinishedFunc when all are loaded */ }

function save()

function restore()
       startAssetLoad(assetsToLoad, start);

function onLoad()
       context = document.getElementById("canvas").getContext("webgl");
       context.addEventListener('webglcontextlost', save, false);
       context.addEventListener('webglcontextrestored', restore, false);

window.addEventListener('load', onLoad, false);

I think that's a reasonably simply structure and requires some pretty standard logic in the internal functions. It requires that the app knows how to save its state and restore to exactly that same state so you can continue where you left off. But that's true for any logic that needs to make the app survive context lost. It's not hard to imagine a data driven app which uses a database library to do the save and restore. That would make the burden on the author for save and restore as light as possible.


I'd need to see more details to see how this works. How do all the async calls that startAssetLoad sets up deal with WebGLContextLost/WebGLContextRestored? If it takes 3 minutes to load the assets (not unreasonable for a game) then it's very possible, you could lose and regain the context after startAssetLoad is called and before initFinishedFunc is called.

You could be in several unknown states when your context is lost and again when it's restored.  This is what seems like an issue with it auto-restoring. It seems like the logic for dealing with auto-restore is extremely hard where has if once it's bad it's bad until the app calls reset it's very easy.


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