fix: upgrade to winit v0.30

[pietrosophya]

trafficstars

Objective

• Upgrade winit to v0.30
• Fixes https://github.com/bevyengine/bevy/issues/13331

Solution

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

Migration Guide

Since the new AccessKit requires to handle properly its events, the custom UserEvent is now an enum with 2 possible values (AccessKit and WakeUp). The latter is used to wake up the loop if anything happens outside the app.

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().

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

Test platforms

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

[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 https://github.com/bevyengine/bevy/pull/13254#issuecomment-2097010522

[alice-i-cecile]

Windowing functionality is working for me on Windows now.

Clear color is broken, but that appears to be #13378.

[alice-i-cecile]

Clippy failures appear to be real / introduced in this PR. Should be an easy fix, but like always let us know if you'd like a hand with anything.

[pietrosophya]

Done now!

[Friz64]

No obvious regression here on Wayland and X11.

[mockersf]

it crashes on iOS f12304112535b479837f44271dc6a165f0001f5d-crash_reports.zip Device logs.txt

[pietrosophya]

Crash fixed on iOS: it was trying to access the AudioSync as a single() component before initializing it.

[alice-i-cecile]

I'm attempting another run on iOS courtesy of Francois's fancy example runner tool. We'll let you know how that goes!

[alice-i-cecile]

Examples appear to be working correctly on iOS now! We should manually verify that I suspect, but that's very good news.

[pietrosophya]

There is one pending failure on testing macos on CI, that depends on winit, but I don't know how to solve this: I tried clearing up WinitWindows (that should contain all the references) but that's not enough. Ideas?

[pietrosophya]

Solved, and I think it's reasonable too.

[mockersf]

WebGL2 doesn't work:

[Error] panicked at crates/bevy_render/src/renderer/mod.rs:185:10:
Unable to find a GPU! Make sure you have installed required drivers!

Stack:

@http://localhost:1236/target/wasm_example.js:1821:30
load_gltf-5001a1b02be6d88f.wasm.wasm-function[console_error_panic_hook::hook::h7a76884a2553e4eb]@[wasm code]
load_gltf-5001a1b02be6d88f.wasm.wasm-function[core::ops::function::Fn::call::h8cfe78e1e00bc822]@[wasm code]
load_gltf-5001a1b02be6d88f.wasm.wasm-function[std::panicking::rust_panic_with_hook::h32c80a64fe4de396]@[wasm code]
load_gltf-5001a1b02be6d88f.wasm.wasm-function[std::panicking::begin_panic_handler::{{closure}}::hd496964d114e98b9]@[wasm code]
load_gltf-5001a1b02be6d88f.wasm.wasm-function[std::sys_common::backtrace::__rust_end_short_backtrace::h0d4686a7fe3981a4]@[wasm code]
load_gltf-5001a1b02be6d88f.wasm.wasm-function[rust_begin_unwind]@[wasm code]
load_gltf-5001a1b02be6d88f.wasm.wasm-function[core::panicking::panic_fmt::hc7427f902a13f1a9]@[wasm code]
load_gltf-5001a1b02be6d88f.wasm.wasm-function[core::panicking::panic_display::h57441543e669293c]@[wasm code]
load_gltf-5001a1b02be6d88f.wasm.wasm-function[core::option::expect_failed::h44ad93b37e925be9]@[wasm code]
load_gltf-5001a1b02be6d88f.wasm.wasm-function[bevy_tasks::single_threaded_task_pool::TaskPool::spawn::{{closure}}::h98b19299c4328dd5]@[wasm code]
load_gltf-5001a1b02be6d88f.wasm.wasm-function[wasm_bindgen_futures::queue::Queue::new::{{closure}}::h065fa42fda1152c3]@[wasm code]
load_gltf-5001a1b02be6d88f.wasm.wasm-function[<dyn core::ops::function::FnMut<(A,)>+Output = R as wasm_bindgen::closure::WasmClosure>::describe::invoke::h277b19d767b55f34]@[wasm code]
__wbg_adapter_60@http://localhost:1236/target/wasm_example.js:241:134
real@http://localhost:1236/target/wasm_example.js:210:21


	(anonymous function) (wasm_example.js:1837)
	load_gltf-5001a1b02be6d88f.wasm.wasm-function[console_error_panic_hook::hook::h7a76884a2553e4eb]
	load_gltf-5001a1b02be6d88f.wasm.wasm-function[core::ops::function::Fn::call::h8cfe78e1e00bc822]
	load_gltf-5001a1b02be6d88f.wasm.wasm-function[std::panicking::rust_panic_with_hook::h32c80a64fe4de396]
	load_gltf-5001a1b02be6d88f.wasm.wasm-function[std::panicking::begin_panic_handler::{{closure}}::hd496964d114e98b9]
	load_gltf-5001a1b02be6d88f.wasm.wasm-function[std::sys_common::backtrace::__rust_end_short_backtrace::h0d4686a7fe3981a4]
	load_gltf-5001a1b02be6d88f.wasm.wasm-function[rust_begin_unwind]
	load_gltf-5001a1b02be6d88f.wasm.wasm-function[core::panicking::panic_fmt::hc7427f902a13f1a9]
	load_gltf-5001a1b02be6d88f.wasm.wasm-function[core::panicking::panic_display::h57441543e669293c]
	load_gltf-5001a1b02be6d88f.wasm.wasm-function[core::option::expect_failed::h44ad93b37e925be9]
	load_gltf-5001a1b02be6d88f.wasm.wasm-function[bevy_tasks::single_threaded_task_pool::TaskPool::spawn::{{closure}}::h98b19299c4328dd5]
	load_gltf-5001a1b02be6d88f.wasm.wasm-function[wasm_bindgen_futures::queue::Queue::new::{{closure}}::h065fa42fda1152c3]
	load_gltf-5001a1b02be6d88f.wasm.wasm-function[<dyn core::ops::function::FnMut<(A,)>+Output = R as wasm_bindgen::closure::WasmClosure>::describe::invoke::h277b19d767b55f34]
	__wbg_adapter_60 (wasm_example.js:241:135)
	real (wasm_example.js:210)

you can build for WebGL2 with cargo run -p build-wasm-example -- --api webgl2 load_gltf, then serve the folder examples/wasm with your preferred tool

[pietrosophya]

Argh, this is kinda blocker for me: in the previous version, a window was created before the loop was started, so that the RenderPlugin was able to build the renderer with an existing PrimaryWindow/RawHandleWrapper. Now this is not easily allowed in winit 0.30, since create_windows is deprecated for the not-running EventLoop, but more than that it doesn't expose the primary_monitor() and available_monitors() methods that are used to build the WindowAttributes.

I tried different solutions:

1. waiting for the PrimaryWindow/RawHandleWrapper inside the RenderPlugin (but it stucks forever on futures::block_on, of course)
2. creating the renderer within a system (even extracting the renderer resources to the RenderApp), but many other plugins require the renderer to be built during the plugin creation phase
3. building the window without monitors info, but they are required to setup a full screen window or in a multi-monitor env

I don't know how to progress here: the ideal solution IMO would be one of these 2:

• build the plugins inside the loop
• create the renderer in a system

but neither is straightforward.

[mockersf]

could you also update the patches in this folder: https://github.com/bevyengine/bevy/tree/main/tools/example-showcase?

They should be applied correctly when you run git apply --ignore-whitespace the-file.patch

[mockersf]

https://github.com/Sophya/bevy/pull/5 fixes WebGL2

[mockersf]

and https://github.com/Sophya/bevy/pull/6 fixes the patches

[pietrosophya]

@mockersf @alice-i-cecile I applied the patches and they work perfectly with WebGL2! Very good job! 💪

[eero-lehtinen]

On android, the app always crashes for me when resuming and starts from the beginning.

05-24 02:33:26.100 20678 20768 I RustStdoutStderr: thread '<unnamed>' panicked at /home/eero/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ndk-context-0.1.1/src/lib.rs:87:5:
05-24 02:33:26.100 20678 20768 I RustStdoutStderr: assertion failed: previous.is_none()
05-24 02:33:26.100 20678 20768 I RustStdoutStderr: stack backtrace:
05-24 02:33:26.101 20678 20768 I RustStdoutStderr: note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
05-24 02:33:26.102 20678 20769 F libc    : Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 20769 (yengine.example), pid 20678 (yengine.example)
05-24 02:33:26.167 20773 20773 F DEBUG   : pid: 20678, tid: 20769, name: yengine.example  >>> org.bevyengine.example <<<
05-24 02:33:26.249 20773 20773 F DEBUG   :       #01 pc 000000000486f980  /data/app/~~kPXnRCpHJL6N6AdQPLvwlg==/org.bevyengine.example-Zcxhs6d14zvubhhjNnV0_g==/lib/arm64/libbevy_mobile_example.so (std::sys::pal::unix::abort_internal::h22ff110bbc1699b8+4)
05-24 02:33:26.249 20773 20773 F DEBUG   :       #02 pc 000000000486a5d4  /data/app/~~kPXnRCpHJL6N6AdQPLvwlg==/org.bevyengine.example-Zcxhs6d14zvubhhjNnV0_g==/lib/arm64/libbevy_mobile_example.so (std::process::abort::h8b8044721853cb0c+4)
05-24 02:33:26.249 20773 20773 F DEBUG   :       #03 pc 00000000042acb88  /data/app/~~kPXnRCpHJL6N6AdQPLvwlg==/org.bevyengine.example-Zcxhs6d14zvubhhjNnV0_g==/lib/arm64/libbevy_mobile_example.so (android_activity::util::abort_on_panic::_$u7b$$u7b$closure$u7d$$u7d$::hc619c8110f14e896+80)
05-24 02:33:26.249 20773 20773 F DEBUG   :       #04 pc 0000000004280044  /data/app/~~kPXnRCpHJL6N6AdQPLvwlg==/org.bevyengine.example-Zcxhs6d14zvubhhjNnV0_g==/lib/arm64/libbevy_mobile_example.so (core::result::Result$LT$T$C$E$GT$::unwrap_or_else::h4ad3ee99af51a99c+88)
05-24 02:33:26.249 20773 20773 F DEBUG   :       #05 pc 00000000042ac604  /data/app/~~kPXnRCpHJL6N6AdQPLvwlg==/org.bevyengine.example-Zcxhs6d14zvubhhjNnV0_g==/lib/arm64/libbevy_mobile_example.so (android_activity::util::abort_on_panic::h571ca68585f5af69+48)
05-24 02:33:26.249 20773 20773 F DEBUG   :       #06 pc 000000000427b7b8  /data/app/~~kPXnRCpHJL6N6AdQPLvwlg==/org.bevyengine.example-Zcxhs6d14zvubhhjNnV0_g==/lib/arm64/libbevy_mobile_example.so (android_activity::activity_impl::glue::ANativeActivity_onCreate::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h6039b1d1285f56aa+44)
05-24 02:33:26.249 20773 20773 F DEBUG   :       #07 pc 00000000042a3214  /data/app/~~kPXnRCpHJL6N6AdQPLvwlg==/org.bevyengine.example-Zcxhs6d14zvubhhjNnV0_g==/lib/arm64/libbevy_mobile_example.so (std::sys_common::backtrace::__rust_begin_short_backtrace::h88e8f4a94008b69d+20)
05-24 02:33:26.249 20773 20773 F DEBUG   :       #08 pc 00000000042b1f88  /data/app/~~kPXnRCpHJL6N6AdQPLvwlg==/org.bevyengine.example-Zcxhs6d14zvubhhjNnV0_g==/lib/arm64/libbevy_mobile_example.so (std::thread::Builder::spawn_unchecked_::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h74db83301323fed3+20)
05-24 02:33:26.249 20773 20773 F DEBUG   :       #09 pc 00000000042afc50  /data/app/~~kPXnRCpHJL6N6AdQPLvwlg==/org.bevyengine.example-Zcxhs6d14zvubhhjNnV0_g==/lib/arm64/libbevy_mobile_example.so (_$LT$core..panic..unwind_safe..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$$LP$$RP$$GT$$GT$::call_once::h5c9ba13d8469e476+20)
05-24 02:33:26.249 20773 20773 F DEBUG   :       #10 pc 000000000427e680  /data/app/~~kPXnRCpHJL6N6AdQPLvwlg==/org.bevyengine.example-Zcxhs6d14zvubhhjNnV0_g==/lib/arm64/libbevy_mobile_example.so (std::panicking::try::do_call::hdabfe2d8d7b53494+60)
05-24 02:33:26.249 20773 20773 F DEBUG   :       #11 pc 000000000428139c  /data/app/~~kPXnRCpHJL6N6AdQPLvwlg==/org.bevyengine.example-Zcxhs6d14zvubhhjNnV0_g==/lib/arm64/libbevy_mobile_example.so (__rust_try+24)
05-24 02:33:26.249 20773 20773 F DEBUG   :       #12 pc 000000000427d7e4  /data/app/~~kPXnRCpHJL6N6AdQPLvwlg==/org.bevyengine.example-Zcxhs6d14zvubhhjNnV0_g==/lib/arm64/libbevy_mobile_example.so (std::panicking::try::ha095ca74b7f3fd9e+72)
05-24 02:33:26.249 20773 20773 F DEBUG   :       #13 pc 00000000042b1e04  /data/app/~~kPXnRCpHJL6N6AdQPLvwlg==/org.bevyengine.example-Zcxhs6d14zvubhhjNnV0_g==/lib/arm64/libbevy_mobile_example.so (std::thread::Builder::spawn_unchecked_::_$u7b$$u7b$closure$u7d$$u7d$::h462da12313516012+364)
05-24 02:33:26.249 20773 20773 F DEBUG   :       #14 pc 00000000042a79d0  /data/app/~~kPXnRCpHJL6N6AdQPLvwlg==/org.bevyengine.example-Zcxhs6d14zvubhhjNnV0_g==/lib/arm64/libbevy_mobile_example.so (core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::hc0e0d53eb775ef24+16)
05-24 02:33:26.249 20773 20773 F DEBUG   :       #15 pc 000000000486eba8  /data/app/~~kPXnRCpHJL6N6AdQPLvwlg==/org.bevyengine.example-Zcxhs6d14zvubhhjNnV0_g==/lib/arm64/libbevy_mobile_example.so (std::sys::pal::unix::thread::Thread::new::thread_start::h2e666d65c6384abd+24)

Also it's pretty easy to quickly open and close the app and then the music keeps playing when suspended. I couldn't get this to ever happen on 0.13 after repeated attempts. Even if closing at just the right time, the music will stop after a couple of seconds in the background, while with this PR it doesn't stop at all.

[alice-i-cecile]

xcodebuild: error: missing value for key 'id' of option 'Destination'

Merge failed due to an iOS failure.

[mockersf]

the only change that could provoke that failure is the makefile change, and I don't see how that could happen

[IQuick143]

I've ran all the windowing examples for testing. (Linux, Xorg, KDE, NVIDIA) Here are my observations:

scale_factor_override

• 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)

window_settings

• Theme changing doesn't work
• Toggling window buttons doesn't work
• NOT a regression, didn't work before either

multiple_windows

• WARN bevy_winit::state: Skipped event Destroyed for unknown winit Window Id WindowId(182452226) upon closing the window, other than a warning it works just fine
• NOT a regression, happened before too

screenshot

• ERROR present_frames: wgpu_core::present: No work has been submitted for this frame before taking the first screenshot, but after pressing space

[happydpc]

I have tested on webgl2, the application will hang when switched tabs. Something like this https://github.com/bevyengine/bevy/issues/13486

[tychedelia]

scale_factor_override

* 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)

Can reproduce on macOS:

Screenshots:

When full screen, text is wonky Minimizing the window then fixes

[alice-i-cecile]

I've asked for help with this PR over in the winit Matrix chat: link.

[eero-lehtinen]

On android, the app always crashes for me when resuming and starts from the beginning.

I did some more testing on Android and it seems that the crashing might be a MIUI quirk. After clearing other background apps, the crashing went away. Sorry for the noise.

Also it's pretty easy to quickly open and close the app and then the music keeps playing when suspended.

I also did some more investigation on this. It is still an issue. It seems that the suspended-function is just never called by winit if the app is closed early enough (at least on my device with Android 11). I don't know if we can do much about it. It is a regression, but maybe not worth blocking over imo. Otherwise suspension works fine.

[eero-lehtinen]

I also tested with opt-level=3 and lto="thin", and then the time window for making the music bug happen is very very small. I couldn't make it happen in practice, maybe it would be easier on a slower device or with more stuff happening in startup.

Edit: tried with 4 second sleep in the setup_music function and easily reproduced the bug with even with optimizations. Would it somehow be possible to listen to the suspension while the Startup schedule is running?

[pietrosophya]

scale_factor_override

* 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)

Can reproduce on macOS:

I think this is related to 2 combined things happening:

1. the scale factor override is only a Bevy internal setup, and it's set in the WindowResolution property of the Bevy Window. There is no counterpart in winit. So the event loop doesn't really react to the change, and a custom event should be emitted instead. It can be handled in the bevy_winit::changed_windows system.
2. winit can send an event for a changed scale factor (easy to repro changing the browser zoom in a WASM app) and the relative event is handled. This is also a source of a bug related to this even in 0.13 (that's a winit one, but can be solved in Bevy too).

I can handle both in this PR or in a follow up one in the next couple days.

[pietrosophya]

I fixed the scale factor override issue and solved this 🤞