bevyengine / bevy

A refreshingly simple data-driven game engine built in Rust
https://bevyengine.org
Apache License 2.0
35.16k stars 3.46k forks source link

Window resizing glitches on MacOS #15004

Open UkoeHB opened 2 weeks ago

UkoeHB commented 2 weeks ago

Bevy version

v0.14.1

[Optional] Relevant system information

MacOS 12.5.1 MacBook Pro

What you did

cargo run --example ui then resized the window.

What went wrong

Additional information

I bisected the problem to [the PR introducing winit v0.30](). It has persisted until now despite #14609 claiming to fix it. See #14255 as a duplicate issue that was closed.

Attached is a video of the problem, showcasing both the top/right banding and the delay (this is cargo run --example ui_wrap_debug, which uses desktop_app() window mode):

https://github.com/user-attachments/assets/6c6fba7a-a9f6-40aa-b54d-9eb0ad482f4b

There is currently an open wgpu PR that fixes part of the problem. However, it doesn't explain the regression from bottom/right banding to top/right banding. I ran the hello_triangle example on wgpu v0.19.3 and got bottom/right banding as expected.

One thing I noticed is we are not calling request_redraw() on the winit window when WindowEvent::Resized is received, even though winit says you need to do so. Unfortunately, adding it manually did not seem to help much.

madsmtm commented 1 week ago

bottom/right banding to top/right banding

Might be https://github.com/rust-windowing/winit/pull/3302, Winit now sets isFlipped on NSViews to match it's coordinate system, might have had unintended consequences for downstream consumers?

UkoeHB commented 1 week ago

@madsmtm hey seems a likely culprit. What would be needed to fix the issue in bevy?

madsmtm commented 1 week ago

No idea, not experienced enough with Bevy to know how they do their rendering. In any case, you could start by trying to use a patched version of Winit with isFlipped set to false so see if that's even the issue?