Skip to content
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

Window resizing glitches on MacOS #15004

Open
UkoeHB opened this issue Sep 1, 2024 · 3 comments
Open

Window resizing glitches on MacOS #15004

UkoeHB opened this issue Sep 1, 2024 · 3 comments
Labels
A-Windowing Platform-agnostic interface layer to run your app in C-Bug An unexpected or incorrect behavior P-Regression Functionality that used to work but no longer does. Add a test for this! S-Needs-Investigation This issue requires detective work to figure out what's going wrong

Comments

@UkoeHB
Copy link
Contributor

UkoeHB commented Sep 1, 2024

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

  • When resizing a window, there is a 'banding' effect on the top and right side of the screen where the app is not rendered. This is a regression from v0.13.0, where the banding effect is on the bottom and right side. Banding at the top causes a lot of glitchiness when the rendered panel reverts itself.
  • If using 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 uses desktop_app() window mode):

bevy_ui_resize_bug_08_31_24.mp4

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.

@UkoeHB UkoeHB added C-Bug An unexpected or incorrect behavior S-Needs-Triage This issue needs to be labelled labels Sep 1, 2024
@tychedelia tychedelia added A-Windowing Platform-agnostic interface layer to run your app in P-Regression Functionality that used to work but no longer does. Add a test for this! S-Needs-Investigation This issue requires detective work to figure out what's going wrong and removed S-Needs-Triage This issue needs to be labelled labels Sep 1, 2024
@madsmtm
Copy link

madsmtm commented Sep 4, 2024

bottom/right banding to top/right banding

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

@UkoeHB
Copy link
Contributor Author

UkoeHB commented Sep 4, 2024

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

@madsmtm
Copy link

madsmtm commented Sep 4, 2024

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Windowing Platform-agnostic interface layer to run your app in C-Bug An unexpected or incorrect behavior P-Regression Functionality that used to work but no longer does. Add a test for this! S-Needs-Investigation This issue requires detective work to figure out what's going wrong
Projects
None yet
Development

No branches or pull requests

3 participants