Add method to enable manual recovery after fatal context lost errors

[hujasonx]

We would like to be able to more gracefully handle loss of opengl context. What are your opinions on adding max-retries attribute or something similar and have model-viewer attempt to re establish the opengl context on context loss?

[DavidPeicho]

Depending on how the context has been lost, I think you don't have any options than to create a fresh
canvas and re-upload everything.

You can't really rely on restoreContext because the context dies "by itself", and you can't wait for a restore event to occur, if for instance the context died because of resource usage (too many contexts create, too much VRAM used).

In a nutshell it's a bit of a tricky problem IMO, because:

• If the context dies because of VRAM usage -> you may not be able to do anything about it
• If the context dies because there are 11 other contexts created -> you can swap with a fresh canvas / context, making the oldest one unusable (oh, snap).
• If the context dies because of WebVR / WebXR / driver update / etc... or whatever, there is a high chance the webglcontextrestored will get triggered.

Maybe I am completly wrong on this, but I haven't found any really good handling of this case.

[cdata]

Thanks for that insight @DavidPeicho. Assuming we wanted to take a stab at this issue, some assorted thoughts:

• Can we test for scenarios where the context can actually be restored? (In other words, can we test for hardware resource availability)
• If our context dies due to too many contexts, it will be a fatal condition because right now we only ever create one. That means all other contexts will be outside our control, and recreating ours with a new canvas will result in seemingly random context loss elsewhere.

@hujasonx a compromise approach might be for us to expose a method on the element to force-restore the context. This would allow the content author, who naturally has a broader understanding of the page and the context where it is running, to decide if and when to attempt a context restore.

That said, I think that given what @DavidPeicho rightly pointed out, restoring the context right now will require a somewhat heavy-handed change (due to the likely need to re-load models, re-generate environment lighting, etc). We would be happy to accept such a change, just keep in mind that it will likely require a bit of work to get it right.

[DavidPeicho]

Can we test for scenarios where the context can actually be restored?

Except doing it manually (using loseContext()and restoreContext()) there is nothing else right now coming out of my mind. You could create your test case by randomly sending a loseContext() followed by a restoreContext() I guess.

a compromise approach might be for us to expose a method on the element to force-restore the context. This would allow the content author, who naturally has a broader understanding of the page and the context where it is running, to decide if and when to attempt a context restore.

Yes, I agree with that, creating a new context without prior knowledge of what the page is doing would be terrible for the end user. But unfortunately, I still didn't find any better idea than swapping the canvas with a fresh one 😢

But at least, exposing an event on-context-lost, with the possibility to do a forceContextRestore() that would swap the canvas with a new one would be great.

[hujasonx]

We do already throw webglcontextlost errors, which we can piggyback off of. Does it make sense to add the opengl error type as an field to the error message so that the application developer can log them or make a more educated decision regarding whether or not to call a forceContextRestore()?

[cdata]

@hujasonx Yah, any contextual info that makes those errors more actionable would be a welcome addition.