-
Notifications
You must be signed in to change notification settings - Fork 644
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wobbly resize (missing or inserted pixel rows/columns) when animation_tick() is used somewhere in an app and using winit #6259
Comments
What operating system and windowing system are you using? |
If it's x11, then this would probably be a duplicate of #5050 . If it's wayland, then maybe this is a bad interaction with the frame event. What's the CPU usage during this? Is it 100%? |
This is on Wayland. The CPU usage isn't very high, 5% maybe. |
Ubuntu 24.04 with Sway WM. |
Thanks for the quick confirmation. |
@tronical what is the problem here? is that not an issue with the renderer? |
I don't think it is. The renderer merely renders into the sub-surface and posts to the compositor, but when that happens in relation to the user input, decorations, and when the compositor shows both together is I'd say part of the wayland protocol interaction. My guess is that the frame callback doesn't work well in conjunction with multiple windows somehow, as when the animation tick window (which triggers frame throttling) is not visible, it's smooth. |
I also see the issue if I use a single window with animation_tick in it. I put two windows just to show that the problem bleeds to other windows too. edit: No sorry I tried again and it indeed requires the two windows. |
(FWIW, I still can't reproduce it on my sway installation, but that doesn't say much) I wonder if the effect is any better if shm is used instead of wayland-egl. Could you try with |
I tried winit-skia before and I could reproduce it, just tried with winit-software and it's also reproducible. |
Thanks for checking :). Makes me think even more that this is more frame related. BTW, do you see the same issue under mutter/gnome/ubuntu, or just sway? |
I didn't try Gnome yet, I'll give it a try this weekend. |
I can reproduce it in Gnome with both Wayland and Xorg. In xorg however I don't see the horizontal compression, only the rendered surface being offset vertically from the top-left corner as seen in the GIF above (but slightly different, the void left isn't white). |
I don't know if it's possible here, but the visual effect reminds me issues I faced elsewhere when drawing wasn't done on the right back buffer. |
Hmm, this debunks another theory I had: that we’re resizing the surface at the wrong time and it ends up out of sync with the decoration (client side). But if this also happens with x11…. Maybe it’s a bug in the graphics driver? |
I asked chatgpt to analyze the WAYLAND_DEBUG=1 logs with and without animation_tick() and the surface seem to be the wrong size (2548, 572 vs 2548, 569). It seems to make sense but I don't know the protocol enough to understand it. https://chatgpt.com/share/67083f7d-eb38-800e-8395-0f89a3742fd3 [2225575.908] [email protected](653070) |
It's only visible during resize, once I stop resizing the rendering looks correct.
Once I close the window containing
animation_tick()
(with the red text), the other window starts behaving correctly.main.rs
Cargo.toml
The text was updated successfully, but these errors were encountered: