slint
slint copied to clipboard
slint-ui
wasm: Handle WebGL context loss
In the language reference docs we have a lot of preview canvases. In Safari those can pretty quick result in a warning and a loss of the WebGL context, rendering the preview invisible.
We should see if we can react to WebGLContextEvent and try to recover when the canvas becomes visible again. This requires re-creating all GL resources, textures, etc., quite similar to unmapping and mapping the window.
Another option would be to use one shared offscreen canvas for all webgl rendering and transfer the result onto each 2d target canvas. This comes at the expense of resizing (at the very least).
Another possibly less effort approach would be annotate some of the canvas elements with a data tag as "static" (as opposed to "interactive") and then discard the context after rendering the frame.
Another possibility is to virtualise the webgl calls, that's implementing the sharing in JS instead of in Rust: https://github.com/greggman/virtual-webgl
I run into this warning by building the same file over and over again. There is only one canvas being rendered into at any point in time, but it keeps changing every time I rebuild.
There should only ever be one GL context at any point in time, I am apparently not cleaning up properly after myself.
I thought about this more and I've come to the conclusion that - unless this virtual-webgl solution easily plugs in - we should switch to entirely CPU based rendering for our previews, possibly all examples. We are using the 3d rendering context to an extent that it is not intended anymore - way to many instances. Perhaps we could trim our resource usage, but I think that would just buy us time, while CPU based rendering would be limited only by general RAM available to the page.
This is a bit of work to implement. Perhaps there's some shortcut that I'm missing. I see either the option of using Skia (which requires wrapping all of our API usage and tunneling through their JS API; and it complicates the deployment) - or adding all features necessary to our software renderer.
It's not so much of a problem for us in the docs, but the problem still exists and it is valid AFAICS. Our wasm builds do rendering using GPU resources without accounting for the fact that those resources may disappear and re-appear.