Firefox/Linux problems with "WebGL context was lost"

[DougBurke]

I have occasional issues with this. At best I can come up with is that this happens the first time I'm accessing the WWT, as I can reload the page and it goes away. My current firefox is 102.0.1 installed on ubuntu via a snap.

This is a new version of the CSC stress test (as it's in prep for the 2.1 release, so more polygons and even-more circles):

https://cxc.cfa.harvard.edu/csc2/wwt21.html

For the user the symptoms is that the page appears to load but either the stack polygons are not shown, or nothing from the WWT is shown. If I use the console log then at some point I see the message

WebGL context was lost.

and then at a later point it shows an error, such as

Uncaught TypeError: WebGL2RenderingContext.shaderSource: Argument 1 is not an object.

Unfortunately I don't think I (as the author) can catch or identify this problem, as it's coming from the WWT code (unfortunately I don't have an example of the problem to show file name/location info), so I don't know how I can let the user know they should try a reload (or if there's some other issue).

[I'm going to be away for a while, so I just wanted to note this in case it's a known problem or has an obvious solution]

[pkgw]

Thanks for reporting! I've actually been looking into this issue recently for a different reason: I find that it often affects me on Firefox/Android, resulting in a blank screen in our apps. Not great!

I don't understand the issues too well, but I think that basically we need the web engine to notice "context lost" events and respond to them by re-acquiring it. As I understand it, if you do it right, there might be a hiccup in rendering but basically the app will be able to keep on working without requiring reloads or anything. At least, sometimes — I think this can also happen when
you run out of memory on the GPU, and stuff like that, in which case I think you also have to reduce the complexity of the scene that you're trying to render if you don't want to get stuck in an unending loop of context-lost events.

When the context is lost, most WebGL routines become no-ops, but the createShader() routine starts returning null, which leads to the TypeError you pasted above. So we'll also need to add some try/catches that basically swallow these errors so that the JS can keep on running.

CC @imbasimba, I know you're busy, but is this an aspect of WebGL that you've dealt with before?

PS:* Also, thanks for the link, it's helpful to have a way to reproduce this on the desktop! I've only encountered the issue on my phone, where debugging is pretty hard.

[DougBurke]

Well,I'm glad it's not just a problem with me ;-)

[imbasimba]

WebGL context is a tricky issue. Ideally we never want to lose the WebGL context, but in reality a bunch of factors outside our control can cause the application to lose the WebGL context. For example, another process may steal the GPU for too long, or WWT and/or another process using too much of the GPU resources.

When the context is lost, the entire WebGL state is lost (all variables and textures, shaders etc), so it is quite tricky to restore everything properly for a complex application like WWT. In theory, it is possible by using our JavaScript variables and context lost/restored events, but it would be an interesting challenge for sure. Currently, WWT is not even listening to these context lost/restored events, so a manual page reload is required.

But if WWT is causing the loss of context, it would be better to track down the root cause instead. It could be something like a memory leak, a serious bug, or extremely inefficient rendering methods (like what we previously had for the circle annotations)

A low effort way to semi-address this would be to add something along these lines:
webglCanvas.addEventListener("webglcontextlost", (e) => { window.location.reload(); });
to reload the WWT page. Of course, this only restarts the app, so all WWT configurations are lost.

[DougBurke]

Can I, not WWT, add this event listener (I don't have time to learn all about webgl at the moment, unfortunately) as a work around?

[imbasimba]

Here is a hacky way of doing it:
document.getElementById("WWTCanvas").children[0].addEventListener("webglcontextlost", (e) => { window.location.reload(); });

If you want to manually trigger a context loss:
gl = document.getElementById("WWTCanvas").children[0].getContext('webgl2'); gl.getExtension('WEBGL_lose_context').loseContext();

[DougBurke]

Can I do this at any time, or is it worth waiting until I've called wwtlib.WWTControl.initControl or waited for the add_ready function to complete?

[imbasimba]

You should be able do it any time after you've called initControl

[pkgw]

@imbasimba Thanks for the help! Let's talk about this more on our next call. On my phone (Android/Firefox), WWT doesn't work most of the time, and I've had other people report the same — it would be good to improve that situation.

[imbasimba]

That is quite serious. Indeed the web client isnt even starting properly on my Android/Firefox, and the research app is starting but does not seem to be able to handle tab switches. I'll try to fit in some kind of investigation into this next week.

[DougBurke]

I've implemented a workaround for my apps thanks to #199 (comment). Hopefully it won't interfere too badly with anything you fix on your end!

[pkgw]

@DougBurke If you get the chance to report back with how well it works for you, that would be super useful! Hopefully we can handle this more gracefully over time.

[DougBurke]

It;s been implemented in both

https://cxc.cfa.harvard.edu/csc2/wwt21.html
https://cxc.cfa.harvard.edu/csc2/wwt.html

so we'll get some feedback (as long as people are using them ;-), although I'm out for most of August so feed-back may be slow