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

Re: [Public WebGL] Addition to WebGLContextLostEvent wrt extensions

On Sat, Apr 10, 2010 at 1:12 AM, Chris Marrin <cmarrin@apple.com> wrote:

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(> >
> 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.

No, it wouldn't. Since a normal GL program does not check for GL errors after initialization then missing assets could just as easily mean they haven't loaded yet, the server was down, any number of reason the author will think of other than the user switched back to read his SMS messages for a moment while the app loaded and it lost context.

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.

My goal is also to make it as simple as possible for the author. My impression is correctly using WebGLContextRestored is far far harder correctly program for than Resetable/ctx.Reset().

In the cases I've listed. Using WebGLContextRestored means I either have to stop all pending loads (more code) or delete all of the bad assets but none of the good ones (more code) and reload just the good ones (more code).

Using Resetable/ctx.reset I just call init again. Simple.  Less code.


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: