Skip to content

Conversation

@aloucks
Copy link
Contributor

@aloucks aloucks commented Mar 1, 2025

Objective

Fixes #18027

Solution

Run redraw_requested logic in about_to_wait on Windows during initial application startup and when in headless mode

Testing

Ran all additional window examples.

Notes:

@aloucks aloucks changed the title Run redraw_requested logic in about_to_wait on Windows during initial application startup Fix window invisible window creation on Windows Mar 1, 2025
@mockersf mockersf added this to the 0.16 milestone Mar 1, 2025
@aloucks aloucks changed the title Fix window invisible window creation on Windows Fix invisible window creation on Windows Mar 1, 2025
@greeble-dev
Copy link
Contributor

I tested the window_settings example and confirmed it's broken on main and fixed with the PR.

However, I was a bit uncertain if the window was really hidden long enough, so I tried increasing the threshold in window_settings.rs/make_visible from 3 to 10 just to see. This broke the example again :[ - the window never appears.

After adding some debug prints, my guess is that it breaks if the app waits for more frames than the default startup_forced_updates of 5.

Testing the PR unchanged:

INFO bevy_winit::system: Creating new window I am a window! (0v1)
about_to_wait self.startup_forced_updates = 5, headless = false
make_visible frames = 0
about_to_wait self.startup_forced_updates = 4, headless = false
make_visible frames = 1
about_to_wait self.startup_forced_updates = 3, headless = false
make_visible frames = 2
about_to_wait self.startup_forced_updates = 2, headless = false
make_visible frames = 3
make_visible setting window.visible = true
WindowEvent::RedrawRequested self.startup_forced_updates = 1
about_to_wait self.startup_forced_updates = 1, headless = false
make_visible frames = 4
WindowEvent::RedrawRequested self.startup_forced_updates = 0
make_visible frames = 5

Aftering increasing make_visible threshold to 10:

INFO bevy_winit::system: Creating new window I am a window! (0v1)
about_to_wait self.startup_forced_updates = 5, headless = false
make_visible frames = 0
about_to_wait self.startup_forced_updates = 4, headless = false
make_visible frames = 1
about_to_wait self.startup_forced_updates = 3, headless = false
make_visible frames = 2
about_to_wait self.startup_forced_updates = 2, headless = false
make_visible frames = 3
about_to_wait self.startup_forced_updates = 1, headless = false
make_visible frames = 4
about_to_wait self.startup_forced_updates = 0, headless = false
about_to_wait self.startup_forced_updates = 0, headless = false
about_to_wait self.startup_forced_updates = 0, headless = false
...repeats forever...

If I then increase startup_forced_updates so it's well above the threshold then the example works again.

SystemInfo { os: "Windows 10 Pro", kernel: "19045" }

@aloucks
Copy link
Contributor Author

aloucks commented Mar 2, 2025

I've added another check to explicitly look for when all windows are invisible. There is some other logic that is driving the update loop based on the visibility status and it has a bunch cfg guards around it. The winnit docs suggest not to drive logic from that status (which is noted in comment in the cfg guards). I didn't want to to attempt to make changes in that area in fear that it might cause some other issue.

Copy link
Contributor

@greeble-dev greeble-dev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Latest version fixes the issues I had. Tested with various delays in window_settings.

@alice-i-cecile alice-i-cecile added A-Windowing Platform-agnostic interface layer to run your app in S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it C-Bug An unexpected or incorrect behavior labels Mar 2, 2025
@alice-i-cecile alice-i-cecile added this pull request to the merge queue Mar 2, 2025
Merged via the queue into bevyengine:main with commit ef9b898 Mar 2, 2025
33 checks passed
aloucks added a commit to aloucks/bevy that referenced this pull request Mar 6, 2025
…indows

The fix in bevyengine#18105 includes a check for running headless, but this allows
for an extra world update during shutdown.

This commit checks if the AppExit event has been recorded and prevents
the additional world update.
aloucks added a commit to aloucks/bevy that referenced this pull request Mar 6, 2025
…indows

The fix in bevyengine#18105 includes a check for running headless, but this allows
for an extra world update during shutdown.

This commit checks if the AppExit event has been recorded and prevents
the additional world update.
github-merge-queue bot pushed a commit that referenced this pull request Mar 6, 2025
…indows (#18175)

# Objective

The fix in #18105 includes a check for running headless, but this allows
for an extra world update during shutdown.

This commit checks if the `AppExit` event has been recorded and prevents
the additional world update.

### Before

```
2025-03-06T03:11:59.999679Z  INFO bevy_window::system: No windows are open, exiting    
2025-03-06T03:12:00.001942Z  INFO bevy_winit::system: Closing window 0v1
2025-03-06T03:12:00.012691Z  INFO bevy_window::system: No windows are open, exiting
```
### After

```
2025-03-06T03:18:45.552243Z  INFO bevy_window::system: No windows are open, exiting    
2025-03-06T03:18:45.554119Z  INFO bevy_winit::system: Closing window 0v1
```
## Testing

Ran `window` examples

- `monitor_info` continues to run after all windows are closed (it has
`ExitCondition::DontExit`)
- `window_settings` invisible window creation works as expected
- `multiple_windows` exits after both windows are closed with a single
exit message
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 S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Application started with a hidden window never actually runs

4 participants