Should THREE.js attempt to automatically recover from a lost context event?

[bhouston]

So I've been playing with the WEBGL_lose_context extension today. It appears that when THREE.js loses context, it just stops and there is no attempt to automatically recover.

In my past life doing DirectX, usually one responds to lost context event by trying to recover the context in response to a "show"-type event. I would suspect that because THREE.js has a mirror of the scene in primary memory, it should be possible in most cases to recover the scene completely by reloading it from primary memory to GPU memory?

Should we make an attempt to recover the lost context automatically? Is there any theoretical or practical reasons why we shouldn't attempt to automatically recover from a lost context in WebGL? Why hasn't this been attempted previously?

I've modified two examples in my branch here so that you can trigger the loss of context:

/examples/#webgl_materials_bumpmap_skin
/examples/#webgl_morphtargets_human

PS. The reason I bring this up as that we know that on Clara.io, we are getting automatic reports of multiple context losses per day. It isn't that frequent give the number of daily users, but it is still something we need to address.

[bhouston]

According to Mozilla developers, lost contexts will happen more and more frequently, especially on tabs that have not recently been used (which I think is our situation for long running Clara.io sessions in the background):

FWIW, we have definite plans to start generating context losses in more cases than we currently do. Currently, aside from the lose_context extension, you only get a WebGL context loss when the
underlying OpenGL context is lost (either through the ARB_robustness watchdog timer, or EGL_CONTEXT_LOST on mobile devices). We ( = Mozilla) plan to lose contexts in increasingly many cases:

• when a given page creates too many WebGL contexts (where too many it at least 8), we'll probably start losing the least recently used context.
• in the farther future, we could well start losing WebGL contexts of tabs that have been inactive for a long time, as part of a more general effort to reduce memory usage for users who have many (sometimes: hundreds) of inactive tabs.

https://groups.google.com/d/msg/webgl-dev-list/gdBxvWKMXVQ/48wWYO9stL4J

[bhouston]

Interesting Firefox developer discussion about how loseContext is called when there is memory pressure and tabs are in the background. And how restore context is called once the tab goes back to visible:

https://bugzilla.mozilla.org/show_bug.cgi?id=998916

[gero3]

I've been looking into this but it isn't a easy as it sounds. But I can take another look into it to make sure it works in the simplest cases first.

[mrdoob]

I think the library should take care of this automatically. I've been working on this for a while and r69 had a step forward on this. In r70dev I even added the method .forceContextLoss() to WebGLRenderer to help with this.

The main reason this doesn't work is because the original design of WebGLRenderer stored the buffers in the Object3D themselves. So if we lose context, the WebGLRenderer will find that buffers have been already created in those Object3D and will attempt to reuse them.

Is not only context lost. Because of this, we can't have multiple WebGLRenderers rendering the same scene.

We'll get there. Someday :)

[Benjamin-Dobell]

@mrdoob The WebGLRenderer has come a long way in the last 18 months, for instance:

Is not only context lost. Because of this, we can't have multiple WebGLRenderers rendering the same scene.

This is now possible.

As such, is there a particular way in which we should be recovering from context loss? I don't mind at all if it's something I need to handle myself rather than three.js, just looking for some advice.

My main issue at the moment is IE11 is giving the following error under very specific circumstances (certain hardware):

WebGL is taking too long to render on your GPU. Temporarily switching to software rendering.

Of course the context is lost when this happens so everything sort of hits the fan. Looking for a recovery mechanism if possible.

Mind you IE11 doing this at all is pretty infuriating. Rendering performance is about 2-3x faster with Chrome or Firefox on the very same machine! It's quite peculiar, unfortunately a major client happens to have a whole heap of machines in their office that all fail in this very fashion.

[mrdoob]

Yeah, I should give priority to this... Hopefully next cycle!

[mrdoob]

#11435