[Public WebGL] OT: exception handling

Florian Bösch [email protected]
Fri Apr 6 09:13:33 PDT 2012

On Fri, Apr 6, 2012 at 6:04 PM, Benoit Jacob <[email protected]> wrote:

> 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.
I agree that you have no choice on current mobile hardware, and it's not
the failing of WebGL to try to handle it. It is still a stupendously bad
idea from a hardware/programming point of view, but unfortunately one we
can't do anything about until in oh, 20 or 50 years or so when GPUs have
arrived in the age of real programmable machines.

> 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....
Crashing of course isn't nice. I'm not convinced that shoehorning
crash-recovery trough context lost is the best idea.

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.
 I think that is a bad idea. You can (in principle) gracefully degrade a
WebGL app without shooting all resources from under it. The context-lost
family of APIs clearly isn't "graceful". I'd urge you to provide a graceful
variant before you become nasty to user code.

Btw. Try to shoot away resources from under any popular WebGL framework and
see how they cope. I don't think three.js copes, and I posit the hypothesis
it'd be virtually impossible to write a usable framework that handles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20120406/07fdb066/attachment.html>

More information about the public_webgl mailing list