Handle lost webgl contexts more gracefully

[ggetz]

When a webgl context is lost, an error is thrown that is not really relevant.

Brought up on the forum here: https://groups.google.com/forum/#!topic/cesium-dev/406L37WfjWs

It looks like the lost context can be specifically checked: https://www.khronos.org/webgl/wiki/HandlingContextLost

[pjcozzi]

Cesium is unlikely to fully restore the state as I suspect potentially doing it in the application is the right level of abstraction, e.g., an app can easily reload a CZML file compared to Cesium tracking and recreating all the renderer/primitive/entity state.

However, we may expose this event if it is widely requested.

Most engines do not implement this AFAIK.

[emackey]

SketchFab shows a friendly dialog box saying something along the lines of "Sorry, but it appears your browser has had a problem running WebGL. Please reload this page to restore functionality." and there's a RELOAD button to click. I realize this is an app-level concern but maybe we could expose some kind of helper for this.

[thw0rted]

I recognize this isn't absolutely universal but I suspect most consuming "apps" use a Viewer (or a directly-managed CesiumWidget) as a cornerstone of the page being viewed. Since the app is likely to be more or less useless with a crashed WebGL, you could show the default error handler with a message along the lines of Ed's suggestions ("Something has gone wrong with your browser's 3D graphics; reloading this page will likely fix the problem.", etc).

That said, if it's a Viewer, I would naively expect it to be possible to destroy the underlying Widget and re-populate it by interrogating viewer.dataSources. That would be far from guaranteed to get back to previous state, but it might be a better user experience than "please click the refresh button".

[tinco]

Hi! We're running into this problem as well. I'd like to catch the webgl context lost event as well. I don't need Cesium to gracefully recover of anything, just something that we get control back and I can reboot cesium would already help a lot.

Also, what kind of thing causes webgl contexts to be lost? It almost never happens to me on my MacBook, nor on my colleagues windows laptop, but our business development guy that does product demo's frequently has them (as you can imagine this is awkward for us) on his surface book. I tried reducing the GPU memory limit, to 256, and that didn't work. We're working with complex models with high resolution textures.

[thw0rted]

I'm developing my (Cesium-based) application on a Surface Book 2 as well. It has a kind of unique 3D graphics situation where the dedicated GPU is in the base and the onboard GPU is part of the tablet/display, so it has to be able to handle seamlessly going between the two. I could definitely imagine a scenario where a glitch in the handoff causes the browser to try and fail to transfer the WebGL context from one to the other, if that makes sense.

I was going to bring up a related issue, about how much detail Cesium is getting from the browser, but when I went back to check the one I was thinking of is actually about initializing the context, not losing it. Still, might be relevant?

[tinco]

Oh jeez you gotta be kidding me. What are the odds that our demo guy is using specifically the unique kind of laptop that might have an issue with creating WebGL contexts.

Maybe I can workaround by when our app is loaded allocate a WebGL context myself, so there's always at least one running and we don't care if that one crashes..

[thw0rted]

A given canvas can only have one (3D) context, and I don't think we have any control over how Cesium manages it. And if there is some kind of rare driver glitch that's causing the context to fail, there's no reason to think it wouldn't cause all active WebGL contexts to fail at once. I think the best thing for it is to set up reasonable error handlers and make the restart process as smooth as possible. If it's happening to you a lot, maybe try a different browser, or capture some debugging information and see if you can report the issue to the browser team. I've had this happen before, but it's certainly not common for me.

[emackey]

Ran into this pretty hard today. Some folks here planned a demo that involves about 20 different Cesium visualizations to be pre-loaded onto various tabs, with cameras placed here and there. Similar demos were frequently given in 2017 and 2018 without issue, but modern versions of Chrome and Firefox are much more aggressive about proactively losing context when it looks like many tabs are hogging up GPU resources. Typically, all Cesium tabs will crash in unison after some idle time.

The problem with simply reloading the page is that it loses one's place. Camera view angle is lost, tracked entity is lost, data source must be re-requested from server, etc.

The workaround for this week's demo is to split up the visualization load across multiple browsers, and possibly across multiple PCs. But longer term, it would be fantastic for Cesium to be able to recover from context loss without losing things like the entity collection and camera position.

[ggetz]

Also requested in #11533