I think the whole idea of context lost is perverted and broken. If a system process runs out of memory. It gets sigtermed, if it oversteps its memory, it gets sighalted, no reasonably programming scheme would do things like silently free memory you've been using. It's why virtual memory managers, swap, protected memory etc. have been invented oh roundabouts 1970 and been thoroughly implemented on all personal computing hardware to around 1985, to being fully supported by any OS by around 1995. GPUs context lost is a barbaric regression to the glory days of 1950 or thereabouts in this regard....
On Fri, Apr 6, 2012 at 6:04 PM, Benoit Jacob <email@example.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.
Back in 1988 we virtualized IRIS GL contexts on the Silicon
Graphics IRIS 4D GT. The hardware supported 16 contexts; if more
were needed they would be swapped in and out.
Unfortunately there is no requirement in today's OpenGL for
drivers to do this. Since there is no way to get a complete dump
of the GL state the only way for an application/OS to do it for
itself is to shadow the GL state.
BTW EGL_CONTEXT_LOST stems from the days of devices such as early
Qualcomm hardware where OpenGL ES ran partially on the DSP and
when that was needed to process an incoming call -
EGL_CONTEXT_LOST. I agree it is a very inelegant design.