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

Re: [Public WebGL] OT: exception handling








On Fri, Apr 6, 2012 at 5:40 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
At least some UA vendors are considering triggering context lost on purpose every so often, just so that it creates visible breakage.
Which nicely demonstrates that context-lost is a bug, rather than a "feature".
 
Unless context lost becomes a reasonably common occurrence, yes?
No. The effort required to handle this is stupendous, and the best-case scenario is that you'll incur considerable reload times for no discernable reason to the user,
On mobile devices at least, we have no choice. First, EGL contexts get lost when (that's why EGL_CONTEXT_LOST exists) so the problem exists anyway and WebGL context lost/restored events are just giving content a chance to recover.

What's more: we're seeing many out-of-memory crashes on Android, where not only Firefox but several system processes (like acore) die (thankfully the android system processes are good at automatically recovering, but Firefox isn't), and are currently investigating losing WebGL contexts on "Low memory" events, as a way to hopefully avoid crashing. Here again, we have no choice (the alternative is to crash) and by firing WebGL lost/restored events we're just giving content a chance to notice and recover. Crashing, as we currently do, sure removes the problem from the Web developer's field, but that's not any better....

Then there are other occurrences where we have a bit more of a choice. We plan to lose WebGL contexts of tabs that have been in the background for a long time. Here we can freely choose the delay, so we can start with a very long delay and gradually reduce it and see if/where we risk causing real-world problems.

Benoit
WebGL living in a webpage being particularly disadvantaged there due to inability to control file-system access (I'm aware of the work-arounds/hacks/hopefuls to "solve" this, no need to discuss them).

The code to re-establish a running application is (in any framework and any web application) the initialization code anyway. The nature of JS makes it very inviting to manage your state in closures and objects. The context lost breaks all your living objects and closures. Re-establishing your running application state on a whim is a seriously non-trivial undertaking. The only remotely reasonable/doable approach is to just hit the reset button on your app and start from scratch. And even so, that just won't be possible for some use cases, which out of necessity retain the resources they work with exclusively in vram (GPGPU, games which make efficient usage of buffers, etc.)

If you (or anybody) thinks shooting live resources from under programmers away will make them more likely to invest a stupendous amount of work to create a miserable user-experience, you're delusional.