GTK 4.14 NGL renderer occasionally clobbers textures used in GL Areas
Steps to reproduce
- Use a glarea under the newest default gtk 4.14 NGL renderer
- Allocate some textures and draw them. I'm not sure if deallocating and reallocating textures on subsequent frames is required or not.
- Render those textures
- Re-render the glarea at least once after that first render (I do this by panning the image in my viewer)
Given the rarity and the fact that this is deep in the internals of my Rust image viewer, I can't easily get to a minimal reproduction. At least it'll take a while to figure out how to do it in C. I can think of how I'd do it but I'm hopeful it won't come to that - a simple application rendering many smallish textures to the screen, and reallocating them on click to try to trigger the issue.
Current behavior
Using the (default) NGL renderer I get occasional, rare instances where one of the textures I allocate in opengl is clobbered by the entire glarea output texture. When I'm deliberately trying to trigger this issue, I can usually reproduce it within a few minutes.
I have been unable to reproduce the bug after switching back to the old GL renderer. Given the rarity it's at least theoretically possible that I could just be really (un)lucky at triggering it again, but I've been trying for most of an hour and I'm now reasonably confident the culprit is something in the gtk 4.14 NGL renderer. I will update this bug if I do hit it with the old GL renderer.
Expected outcome
This should never happen.
Version information
GTK 4.14.3, Fedora, x11/i3. Nvidia 550.78
I did have a recent update from nvidia 550.67, but that happened a few days before the update to gtk 4.14 from 4.12. It's a pretty rare issue but I've been hitting >1 a day organically, I think it's likely I'd have encountered this issue in those few days if it was a driver issue.
Additional information
For large images I have a tile-based renderer, and occasionally one of the tiles will get clobbered by the glarea's output buffer (or at least that's what I assume this inverted texture is). Even more rarely this will happen when I'm rendering a single image, in which case I usually get a black screen immediately or on the second render. More textures does seem to make clobbering more likely, but not any more than I'd expect when comparing one trial with N textures against N trials with one texture.
I've been running this rendering code almost two years now, and it has been stable and and at least free of rendering bugs/corruptions that are anything like this.
If I run the vulkan driver - which I know isn't supported right now on nvidia - I run into the same issues instantly. So if there's some commonality between NGL and vulkan, that might be relevant. If I run the cairo renderer I don't appear to run into the issues, but the performance is too low for me to leave it on for longer-term testing.
The textures are being named by a fresh glGenTextures
in my code so I expect something in GTK is reusing texture names after a glDeleteTextures
call.