[Public WebGL] OT: exception handling

Benoit Jacob [email protected]
Fri Apr 6 09:04:15 PDT 2012

----- Original Message -----

> On Fri, Apr 6, 2012 at 5:40 PM, Boris Zbarsky < [email protected] >
> 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. 


> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20120406/96d16af8/attachment.html>

More information about the public_webgl mailing list