Open adenine-dev opened 4 months ago
Does it happen in the example we use?
Of the examples in the winit repo, control_flow (only when set to 3/poll or when redraw requested is enabled), pump_events, and run_on_demand, exhibit the behavior, while child_window and window do not.
Additionally control_flow when set to poll/with redraw requested, causes multiple seconds of lag, which is weird because in my application when I turn off rendering, even while updating continuously it does not cause this issue.
Only window should not do that, because window has correct render loop, the rest is just to show how things kind of work.
If window
doesn't it could be just macOS being slow with hardware acceleration surfaces.
window
indeed does not do it, only control_flow
, pump_events
, and run_on_demand
.
Not really sure what you mean abt hardware acceleration surfaces, other applications I know are using metal do not exhibit this behavior. (specifically i tested a C app using metal and sdl3, and it didn't have this issue).
Just tested this using the sdl2 crate, specifically this variant of it since it doesn't work with wgpu on main rn, and it doesn't have this issue, It is slightly more laggy than other applications so wgpu may be partially at fault, but its no where near how laggy winit is.
But winit itself in example is not laggy as you said with the way it's doing things and its window
example with the desired control flow is not laggy as well?
I think this might be a duplicate of https://github.com/rust-windowing/winit/issues/1737.
I think this might be a duplicate of #1737.
I saw this too but the last comment says it doesn't apply with rectangle so i figured it was different, magnet and bettertouchtool are both paid so i can't test them unfortunately.
But winit itself in example is not laggy as you said with the way it's doing things and its
window
example with the desired control flow is not laggy as well?
While the window
example in this repo does not exhibit the behavior, the example also does not change the control flow or update continuously, the examples in this repo that do update continuously do show this behavior.
@adenine-dev if you resize it it'll update contiguously, so I don't see an issue here? It's updated as you want when it needs to be, you can also make it update contiguously.
Rectangle snaps to various locations in the screen, similar to how on windows if you drag a window to the side it will snap to filling half of the screen. So its not resizing continuously its snapping and resizing once (or technically twice because of the way rectangle is implemented). Additionally the lag occurs even when repositioning the window (ie when snapping from the left half of the screen to the right half, but maintaining the same size). This lag does not occur when resizing manually, or if it does it is not noticeable.
I hope the attached video clarifies, here it is first in wait mode and I spam the rectangle snap shortcuts, then when i change the control flow to poll and spam them again it is very laggy. I'm spamming the shortcuts at the same speed both times.
*edited to remove the linked video
@adenine-dev I have experienced this as well. I haven't studied it in depth, and for now the main way I've worked around it is to artificially limit my drawing frequency based on time as you can see here.
I don't think this is a great solution though because it probably misses some frames when resizing, which would result in flickering or incorrectly rendered output sizes.
It seems the act of rendering, presumably with vsync enabled, makes the redraw event take quite some time, and maybe multiple RedrawRequested events stack up and cause lag. I'd have to look more into the winit code to see for sure.
@bschwind Thanks, this works really well,,
idk about your system, it looks like you're potentially getting the desired fps from the monitor, but the maximum variance I've noticed when resizing with this method is ~+100% dt at 120fps, which is a lot but seeing as its an "instant" resize, only occurs for one tick, and this behavior does not occur on "normal" drag resize, its more than good enough for my purposes.
this is still probably a bug in winit, so i'll leave the issue open but hopefully anyone who finds this in the future can learn from it
Thanks again ^^
Glad that works for you, at least as a workaround. I decided to start digging into the winit code a little bit but so far I haven't come up with anything.
I did find this post from 2019 which may have some hints on it, though:
https://thume.ca/2019/06/19/glitchless-metal-window-resizing/
In any case, I'll keep looking into it as it would be a satisfying bug to fix.
Description
On macos when resizing windows with the rectangle utility, winit windows that
request_redraw
continuously with rendering, lag when resizing/repositioning with rectangle. This lag varies but is typically ~200ms-500ms.While rendering is required (namely
SurfaceTexture::present
or equivalent), the bug occurs with multiple backends (tested with wgpu and vulkano), on my machine no other application exhibits this behavior, including ones that render continuously so I don't think its a rectangle bug either.This bug occurs no matter where I put the rendering code, or how I update it, I've tested with rendering in
Event::AboutToWait
andWindowEvent::RedrawRequested
I've also tested with withControlFlow::Poll
andControlFlow::WaitUntil
manually targeting 60fps, all cases I could find exhibit this behavior.Minimum reproducible: wgpu triangle example, modified to render continuously:
alternately, the boids example exhibits this behavior without modification.
macOS version
Winit version
0.29.15