Skip to content

Fix winit control flow when re-focusing game#12239

Merged
alice-i-cecile merged 5 commits into
bevyengine:mainfrom
thebluefish:ff_winit_fix
Mar 4, 2024
Merged

Fix winit control flow when re-focusing game#12239
alice-i-cecile merged 5 commits into
bevyengine:mainfrom
thebluefish:ff_winit_fix

Conversation

@thebluefish

Copy link
Copy Markdown
Contributor

Objective

Fixes #12126

Notably this does not appear to fix the console error spam that appears to be coming from winit, only the performance bug that occurs when tabbing out and back into the game.

Solution

The winit event loop starts out as ControlFlow::Wait by default. When switching to UpdateMode::Reactive or UpdateMode::ReactiveLowPower, we repeatedly update this to ControlFlow::WaitUntil(next). When switching back to UpdateMode::Continuous, the event loop is erroneously stuck at the latest ControlFlow::WaitUntil(next) that was issued.

I also changed how we handle Event::NewEvents since the StartCause already tells us enough information to make that decision. This came about my debugging and I left it in as an improvement.

@alice-i-cecile alice-i-cecile added this to the 0.13.1 milestone Mar 1, 2024
@alice-i-cecile alice-i-cecile added C-Bug An unexpected or incorrect behavior O-Web Specific to web (WASM) builds A-Windowing Platform-agnostic interface layer to run your app in labels Mar 1, 2024
@alice-i-cecile alice-i-cecile added the S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it label Mar 4, 2024
@alice-i-cecile alice-i-cecile added this pull request to the merge queue Mar 4, 2024
Merged via the queue into bevyengine:main with commit d6a7319 Mar 4, 2024
mockersf pushed a commit that referenced this pull request Mar 5, 2024
# Objective

Fixes #12126

Notably this does not appear to fix the console error spam that appears
to be coming from winit, only the performance bug that occurs when
tabbing out and back into the game.

## Solution

The winit event loop starts out as `ControlFlow::Wait` by default. When
switching to `UpdateMode::Reactive` or `UpdateMode::ReactiveLowPower`,
we repeatedly update this to `ControlFlow::WaitUntil(next)`. When
switching back to `UpdateMode::Continuous`, the event loop is
erroneously stuck at the latest `ControlFlow::WaitUntil(next)` that was
issued.

I also changed how we handle `Event::NewEvents` since the `StartCause`
already tells us enough information to make that decision. This came
about my debugging and I left it in as an improvement.
spectria-limina pushed a commit to spectria-limina/bevy that referenced this pull request Mar 9, 2024
# Objective

Fixes bevyengine#12126

Notably this does not appear to fix the console error spam that appears
to be coming from winit, only the performance bug that occurs when
tabbing out and back into the game.

## Solution

The winit event loop starts out as `ControlFlow::Wait` by default. When
switching to `UpdateMode::Reactive` or `UpdateMode::ReactiveLowPower`,
we repeatedly update this to `ControlFlow::WaitUntil(next)`. When
switching back to `UpdateMode::Continuous`, the event loop is
erroneously stuck at the latest `ControlFlow::WaitUntil(next)` that was
issued.

I also changed how we handle `Event::NewEvents` since the `StartCause`
already tells us enough information to make that decision. This came
about my debugging and I left it in as an improvement.
mtsr pushed a commit to mtsr/bevy that referenced this pull request Mar 15, 2024
# Objective

Fixes bevyengine#12126

Notably this does not appear to fix the console error spam that appears
to be coming from winit, only the performance bug that occurs when
tabbing out and back into the game.

## Solution

The winit event loop starts out as `ControlFlow::Wait` by default. When
switching to `UpdateMode::Reactive` or `UpdateMode::ReactiveLowPower`,
we repeatedly update this to `ControlFlow::WaitUntil(next)`. When
switching back to `UpdateMode::Continuous`, the event loop is
erroneously stuck at the latest `ControlFlow::WaitUntil(next)` that was
issued.

I also changed how we handle `Event::NewEvents` since the `StartCause`
already tells us enough information to make that decision. This came
about my debugging and I left it in as an improvement.
@extrawurst

Copy link
Copy Markdown
Contributor

@thebluefish this seems to break an app doing requestReviewInScene and the user clicking it away: after that the app will not update anymore by itself, but only if a winit-event like touches arrive

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 O-Web Specific to web (WASM) builds 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.

Performance Issues in WASM Builds When Refocusing in Firefox

4 participants