Open UkoeHB opened 2 weeks ago
bottom/right banding to top/right banding
Might be https://github.com/rust-windowing/winit/pull/3302, Winit now sets isFlipped
on NSView
s to match it's coordinate system, might have had unintended consequences for downstream consumers?
@madsmtm hey seems a likely culprit. What would be needed to fix the issue in bevy
?
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?
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
desktop_app()
window mode, the window does not update immediately after a resize despite receiving a resize event (presumably).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 usesdesktop_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 onwgpu 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 whenWindowEvent::Resized
is received, even thoughwinit
says you need to do so. Unfortunately, adding it manually did not seem to help much.