[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 11:16, Gregg Tavares <firstname.lastname@example.org>
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.
If you lose the context during asset load, further loading will fail fast with appropriate gl.CONTEXT_LOST error or equivalent, which means the asset loading code should stop and initFinishedFunc would not be called; I'm not sure how calling manually a resetContext() function in a WebGLContextReady event handler would change something about this?
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.
Once it's bad it's bad whenever you handle a ContextLost event until a ContextRestored is handled.
If the app calls reset, the context might be lost just after the call as well, so there is still no guarantee either that "once it's good it's good".