UI jittering/flickering on fast window resize with glow

[cmot17]

Describe the bug
When the window is resized at high speed, the UI starts to flicker/jitter.

To Reproduce
Steps to reproduce the behavior:

1. Run the eframe example.
2. Resize the window fast.

Expected behavior
For the elements of the UI to stay put during resizing

Screenshots
Here's a quick screen recording displaying the issue:

windowresize1080.mov

Desktop (please complete the following information):

• OS: MacOS Montery 12.0.1
• M1 Max SoC - if that's applicable at all

[emilk]

Something similar also happens with egui_web when resizing the browser window.

I would like to get this fix. A good start would probably be to investigate other OpenGL-based GUI/renderers and see if they have the same issue (using winit, glutin and for WebGL canvas).

[emilk]

Interestingly this does not happen with the new egui-wgpu backend (#1564)

[w-ensink]

I have the same issue, also on M1 Max. The same problem arrises when I run some of the examples for imgui-rs.

[yay]

Yeah, it's quite severe. I'm also using this on a mac, but this is not macOS related right?
https://user-images.githubusercontent.com/1799756/171958702-ceb8ef14-7181-4e66-88c0-a36b9b57165d.mp4

[amPerl]

seeing this on latest eframe as well, fresh macos monterey on m1 pro

edit: could it be refresh rate shenanigans?
edit2: nope, switching to fixed 60hz changes nothing

[paulrouget]

bisect points to: b1fd6a4

[emilk]

@paulrouget Thanks for that bisect! So that's when we switched from glium to glow. I wonder what else changed there. How we set up the swap-chain perhaps? Or something about the event loop?

[paulrouget]

Hmm… I found flickering in previous commits as well. But it's less pronounced. It also depends on what's on screen and the speed the mouse move. Going back to 3e1db88 the jitter happens (less pronounced than b1fd6a4 but still happening). Before that, resizing is not jittery anymore, but instead of jitter, we get stretched UI.

Basically, on my Mac M1, no matter how far back I go, resizing doesn't worked properly.

Enabling wgpu backend fixes the issue.

[wareya]

Resizing windows on Windows 10 using eframe 0.19 on my system results in extremely bad hard flickering, like the window pane is getting cleared white between rendering updates. It happens with both rendering backends. 0.18 doesn't have this problem. Is this another manifestation of this bug or should I open a new issue?

(SEIZURE WARNING. 0.19)
https://user-images.githubusercontent.com/585488/191777393-6876e0ce-fbf4-4ff3-a487-e6fd1e541a02.mp4

(0.18)
https://user-images.githubusercontent.com/585488/191777412-5d1d87d7-02f1-4c48-91f0-0abe15a04897.mp4

[yay]

@emilk This is still the case in 0.4:
https://user-images.githubusercontent.com/1799756/194758951-0d0ab6c1-b608-4425-9fc4-87b87c59f899.mp4
This is the same footage played frame by frame:
https://user-images.githubusercontent.com/1799756/194758964-4aedfd50-f0fc-4f4d-a483-422e93c8047a.mp4

It looks like every other frame the layout size is incorrect.

[emilk]

@wareya oh wow, that flickering is really bad 🙈 - please open a separate issue. Does switching to wgpu solve it?

[emilk]

@emilk This is still the case in 0.4:

0.4 of what?

[yay]

Sorry, 0.19. I took this screen capture today by checking out master of https://github.com/emilk/egui

[yay]

Looks like layout is not the only issue and the content can visibly scale before it has a chance to rerender:
https://user-images.githubusercontent.com/1799756/199849237-529eb557-d313-4148-89e6-6923c9650e24.mp4
These layout shifts and content scales alternernate without any distinct pattern to it.

[yay]

And the scaling issue is not present with wgpu backend: https://github.com/hasenbanck/egui_example
https://user-images.githubusercontent.com/1799756/199847122-332d1ec9-9be9-4471-9529-8c4a0027725e.mp4

Compare to the default glow backend:
https://user-images.githubusercontent.com/1799756/199847154-1834c7a0-2786-47b6-8904-ee1b29c03fa2.mp4

Layout issue is there in both backends but comparatively minor (can be noticed by looking at the right-docked sidepanel while dragging the left edge of the window):

(wgpu) https://user-images.githubusercontent.com/1799756/199847811-84e72d0d-3e48-4712-bb02-74d7b54b9965.mp4

(glow) https://user-images.githubusercontent.com/1799756/199847832-c9bc4ccb-27c6-4287-bb5c-9ece1a98bb6e.mp4

[andrew-gropyus]

@emilk did you accidentally close this (edit: or github prematurely closed it) when merging #2280?

Here is a screen capture from the current head, 690dc2d, which shows the same behaviour as the original report:

Screen.Recording.2022-11-14.at.11.55.43.mov

[emilk]

You are right, that was a mistake

[LoganDark]

I forgot to change the PR title after @emilk said that macOS still had the issue, my apologies

I think this could safely be labeled as a macOS-only issue though, if someone can test it on Linux (X11/Wayland) and have the issue not be present

I used to have a Linux install to test with, but my MacBook broke so I don't anymore :(

[kud1ing]

Not sure whether it helps: i've noticed that the effect does not appear with:

• egui examples:
  • hello_world_par (uses wgpu)
  • screenshot (uses wgpu)
• bevy_egui
• egui-miniquad
• rerun (uses wgpu?)

[LoganDark]

Not sure whether it helps: i've noticed that the effect does not appear with:

• egui examples:

  • hello_world_par (uses wgpu)
  • screenshot (uses wgpu)

• bevy_egui

• egui-miniquad

• rerun (uses wgpu?)

this is because the issue is with glow, which is how eframe presents the egui framebuffer to a window. those are all different integrations that do not use glow

[DouglasDwyer]

For me, this jittering effect does occur on Windows 10 with egui-wgpu. When I run the hello_world_par example, resizing the window leads to the same distortions shown in the other videos in this thread. I do not observe any problems with the hello_world or hello_world_simple examples, though.

[Auvrae]

This issue does not happen in 0.23.0, it only starts occurring in 0.24.0. I know that's a very old version. It's just the version that I was using when I started using egui, when I updated my app to the latest version, I noticed this issue. I went from 0.23.0 -> 0.27.2 and then started going backwards with versions until I found a version that this issue did not occur on, which I did not find. The only stable resizable version is 0.23.0.

I also tried as suggested above all of the examples and it happens in every single one for me on the latest version. I didn't try each version + each example though.

OS: Linux / Window
Wayland & X11 tried

[Auvrae]

Using the latest commit seems to be working as intended without the shuttering / floating problems, widgets are aligned and sit in their place.

[j-n-f]

Using the latest commit seems to be working as intended without the shuttering / floating problems, widgets are aligned and sit in their place.

@nurdyAuv what platform and backend are you using?

I'm on Win10 and using master I get:

• glow - flickering when switching to/from fullscreen, resize looks fine
• wgpu - no flickering when switching to/from fullscreen, but stretching on resize and fullscreen toggling

[Auvrae]

Platform: Linux (rolling release), Windows 10 22H2
Renderer: Glow
Rust: 1.77.2

I didn't test fullscreen, just resizing. But I'll test that later.
How do I enable wgpu? It's enum isn't available when I make the native options.

[Auvrae]

glow - flickering when switching to/from fullscreen, resize looks fine

@j-n-f i'm not seeing the flickering switching between fullscreen and back, on Windows or Linux on the master branch with the latest commit.

[j-n-f]

Interesting. I have some applications that can go fullscreen without flickering, and others which do flicker. I might guess it was a driver issue, but if it was a driver issue I'd expect it to be the same for all applications that can go full screen. I'll have to learn more about glow and wgpu to debug further. What would be really handy would be the ability to save the last N frames of graphic buffer state. Then it might be easier to drill down into what's happening at the exact moment the output is distorted. With glow it looks like it renders a frame when the window size changes but with incorrect values for the overall size of the full app rect. (I actually could come up with a way to monitor/verify this in my app code). With wgpu it looks like the window size changes before surfaces are redrawn (so it gets blown up or shrunk down). I'm less sure how I would debug that.

…

-------- Original Message --------

On 2024-05-30 5:34 p.m., Mel wrote: > * `glow` - flickering when switching to/from fullscreen, resize looks fine ***@***.***(https://github.com/j-n-f) i'm not seeing the flickering switching between fullscreen and back, on Windows or Linux on the master branch with the latest commit. — Reply to this email directly, [view it on GitHub](#903 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/BE5NXZAP3KE7MFBHEFM2LODZE6LNNAVCNFSM5IMIIFNKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJUGA4DSOBVG44A). You are receiving this because you were mentioned.Message ID: ***@***.***>

[cyypherus]

I was able to reproduce the exact same stuttering with this femtovg / winit example application (you have to enable window resize in the code)
https://github.com/femtovg/femtovg/blob/master/examples/text.rs

Screen.Recording.2024-11-12.at.9.40.27.PM.mov

I think this is related to how earlier versions of winit call redraw. The graphics are being scaled along with the window between redraws.

I think this may be fixed in newer versions since I cargo updated (-b) & my example app no longer stutters.

These are the versions I upgraded to - in case any others are related as well.

winit = { version = "0.30.5", default-features = false }
cosmic-text = { git = "https://github.com/pop-os/cosmic-text", rev = "e00109d77f06d5a2e3057865eda3f530bc40a046" }
swash = "=0.1.17" # keep this in sync with cosmic-text
femtovg = "0.10.1"
glutin = "0.32.1"
glutin-winit = "0.5.0"
raw-window-handle = "0.6.2"