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

Re: [Public WebGL] OT: exception handling



On Fri, Apr 6, 2012 at 6:04 PM, Benoit Jacob <bjacob@mozilla.com> 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 context-lost.