fix: upgrade to winit v0.30

[pietrosophya]

Objective

• Upgrade winit to v0.30
• Fixes bevy mobile example crashes on Android #13331

Solution

This is a rewrite/adaptation of the new trait system described and implemented in winit v0.30.

Migration Guide

The custom UserEvent is now renamed as WakeUp, used to wake up the loop if anything happens outside the app (a new custom_user_event shows this behavior.

The internal UpdateState has been removed and replaced internally by the AppLifecycle. When changed, the AppLifecycle is sent as an event.

The UpdateMode now accepts only two values: Continuous and Reactive, but the latter exposes 3 new properties to enable reactive to device, user or window events. The previous UpdateMode::Reactive is now equivalent to UpdateMode::reactive(), while UpdateMode::ReactiveLowPower to UpdateMode::reactive_low_power().

The ApplicationLifecycle has been renamed as AppLifecycle, and now contains the possible values of the application state inside the event loop:

• Idle: the loop has not started yet
• Running (previously called Started): the loop is running
• WillSuspend: the loop is going to be suspended
• Suspended: the loop is suspended
• WillResume: the loop is going to be resumed

Note: the Resumed state has been removed since the resumed app is just running.

Finally, now that winit enables this, it extends the WinitPlugin to support custom events.

Test platforms

• Windows
• MacOs
• Linux (x11)
• Linux (Wayland)
• Android
• iOS
• WASM/WebGPU
• WASM/WebGL2

Outstanding issues / regressions

• iOS: build failed in CI
  • blocking, but may just be flakiness
• Cross-platform: when the window is maximised, changes in the scale factor don't apply, to make them apply one has to make the window smaller again. (Re-maximising keeps the updated scale factor)
  • non-blocking, but good to fix
• Android: it's pretty easy to quickly open and close the app and then the music keeps playing when suspended.
  • non-blocking but worrying
• Web: the application will hang when switching tabs
  • Not new, duplicate of winit::TabLeft/Event::Suspended doesn't function as intended on WASM #13486
• Cross-platform?: Screenshot failure, ERROR present_frames: wgpu_core::present: No work has been submitted for this frame before taking the first screenshot, but after pressing space
  • non-blocking, but good to fix

[alice-i-cecile]

Does anyone have opinions on squeezing this into 0.14 vs merging it at the start of 0.15? On the one hand fixes are great, on the other hand these upgrade PRs are consistently incredibly painful to review and introduce a large number of new bugs that must be manually tested.

[pietrosophya]

IMHO, this could be finished and merged as part of 0.14: I only moved code from free variables and functions inside the WinitAppRunnerState, not really changing any logic.

Also, apart from testing it, the number of missing/required changes is not high: I just need to understand better the AccessKit part, restore the exit flags (that aren't currently working) and compile/test the various platforms.

The low_power example (and I believe others too) in MacOS works already.

[hymm]

I think android support is broken without the update. See this message from Francois #13254 (comment)

[mockersf]

Could you give me more details on the iOS build failure? I don't see it in CI, I'll try to reproduce tomorrow

also, another patch update please: Sophya#7

[tychedelia]

Could you give me more details on the iOS build failure? I don't see it in CI, I'll try to reproduce tomorrow

Seems like iOS is skipped? This happened last time it was added to the merge queue: https://github.com/bevyengine/bevy/actions/runs/9215755498/job/25354702941

[aevyrie]

FYI: this fixes an issue on main, where mouse inputs are only reported every other frame on MacOS.

[tychedelia]

FYI: this fixes an issue on main, where mouse inputs are only reported every other frame on MacOS.

Oh wow, just tested and this is extremely noticeable on one of my apps running in debug mode. I was wondering yesterday how it could possibly feel so sluggish. Huge fix!

I am seeing an issue however around startup where there is some rescaling visible.

Screen.Recording.2024-06-02.at.9.39.46.AM.mov

In this video it's pretty instant but it's seemed to hang just a bit longer a few times.

[alice-i-cecile]

@pietrosophya once you commit the changes suggested in #13366 (comment) to fix the iOS build I'll merge this in.

[Friz64]

FYI: this fixes an issue on main, where mouse inputs are only reported every other frame on MacOS.

I think it has also been happening to me on Wayland. Oh wow.

@pietrosophya once you commit the changes suggested in #13366 (comment) to fix the iOS build I'll merge this in.

Sophya#7 is also still waiting.

[aevyrie]

FYI: this fixes an issue on main, where mouse inputs are only reported every other frame on MacOS.

It appears the issue is not completely fixed, there are still frames where inputs are missing, but it is measureably improved.

[pietrosophya]

Patch #7 applied, and also accepted/reverted the change for building iOS

[alice-i-cecile]

Thank you to everyone involved with the authoring or reviewing of this PR! This work is relatively important and needs release notes! Head over to bevyengine/bevy-website#1328 if you'd like to help out.

[HugoPeters1024]

I'm in the process of migrating my custom rendering backend to work with Bevy 0.14 and I'm running into trouble because the RawWindowHandleWrapperHolder contains a None value when initializing my rendering plugin. At what point can I rely on the value being set?