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

Re: [Public WebGL] Addition to WebGLContextLostEvent wrt extensions



On Apr 9, 2010, at 2:52 AM, Gregg Tavares wrote:

> 
> 
> ...I'm not sure what you mean. No matter what model you use, if you're not checking for errors while using an object, you will get incorrect results. In your example, if the machine were shutdown while writing a file, one of those f.write calls would return an error. You'd then know the written file is corrupt. When the device was restored, you'd destroy that file, open a new one and ask the provider for the data again. I don't see any way around this, regardless of the semantics of the API.
> 
> Am I misunderstanding the problem?
> 
> The problem I'm imaging is that a typical GL programmer will take old code that was like this
> 
> Do1000InitializationSteps();
> RunMainLoop();
> 
> They'll change it to
> 
> Do1000IntializationStepsAsync(onFinished=RunMainLoop);
> 
> They don't check for every possible error.
> 
> During those 1000 steps they get WebGLContextLost and WebGLRestoreContext which they didn't bother to put handlers for.
> 
> By the time the code gets to runMainLoop everything seems fine but it's not.  Every resource created before WebGLContextLost is bad. They won't check for errors during the main loop because that's bad form for GL programs.  So, their app has a few textures missing or a few something else is not setup correctly but because behind the scenes the lost context was auto restored they have no idea what happened.
> 
> If there was no auto-restoring of the context then their program would fail for sure when they got to RunMainLoop and they'd fix the issue.

Any assets loaded before the ContextRestored event would be lost so that would be a pretty clear indication. Sounds like your concern is what happens if you lose the context near the start of your asset loading and it gets restored before most have loaded. Then you'd see most but not all assets loaded and the error would (possibly) be less obvious. That's a good concern.

I think it would be possible and reasonable to keep the context invalid until the WebGLContextRestored event were serviced. That means the context would stay invalid forever if the author did not handle the WebGLContextRestored event, which is a good thing. And it would make the error obvious, as in your scenario.

My goal is to avoid extra functions and make it as easy to deal with for the author as possible.

-----
~Chris
cmarrin@apple.com




-----------------------------------------------------------
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: