[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 12:59 PM, Cedric Vivier <email@example.com>
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;
lost context has nothing to do with how long it takes to load an image. If I start 3 images loading. The first one takes 3 seconds, the next 6 and the last 9. If I lose the context at 4 seconds and it gets restored at 8 only the second image will fail with gl.CONTEXT_LOST. The first image is bad by definition, it was created with a lost context. The 3 image was created after the context was restored and is therefore valid. Now I have this strange state where the beginning of my initialization failed but the end succeeded.
I'm not sure how calling manually a resetContext() function in a WebGLContextReady event handler would change something about this?
Because in the example above it would mean all 3 images are bad instead of just the first 2 since I could choose to not call reset until I was ready for things to start succeeding.
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".
That's fine. I'm not concerned with good. That's not the issue. This issue is it needs to stay bad until I'm ready for it to possibly be good.