`bevy_assets` should send wake events to `bevy_window` when assets finish loading (async tasks and `desktop_app` interactions)

[alice-i-cecile]

What problem does this solve or what need does it fill?

When running in desktop_app mode, applications can get "stuck" in an unloaded or partially loaded state.

This leads to bugs like #20796.

What solution would you like?

The AssetServer should send wake events whenever assets are finished loading, if we're running in a mode like desktop_app. That's pretty hand-wavey, so there's more digging to do before we can implement this.

This is quite hard to do though: the App code is fully paused without user inputs. Somehow, we need to be regularly and efficiently polling even when the app is asleep. Apparently egui / bevy_egui do a better job of this (thanks @aevyrie), so looking there for prior art would be wise.

What alternative(s) have you considered?

Don't use desktop_app, as we did in #20851 as a workaround. This isn't viable in the long-term though: input-driven windowing provides better responsivity and power efficiency.

[alice-i-cecile]

I'm not familiar with the nitty gritty of that, but the general pattern for truly async stuff is to kick the event loop proxy at the end of any async task.
We do that with our background task and networking abstractions. The event loop can go to sleep, async io can be running concurrently, then kick the bevy event loop when it finishes to, e.g. spawn something or update the UI.
It might be desirable to do this out of the box automatically for all of bevy's async tasks. The risk there is you might have a background task that you don't want to wake the event loop, it's okay for the result to sit and wait to be picked up by the next event loop run whenever that is.

• @aevyrie, on how it's done over at Foresight.

[aevyrie]

It's probably worth considering making all asynchronous tasks kick the event loop proxy when they complete. It's a pretty common footgun to wonder why you need to wiggle the mouse when an asynchronous task completes but the app doesn't wake.

It would be nice to have control over this as a user though. The vast majority of the time you want this behavior, but when you care about power use it's nice to explicitly opt into what wakes the event loop. It also means you can grep for usage of the event loop proxy when you inevitably run into bugs where the app never goes to sleep. (I've seen this happen and regress multiple times 😧)

Another option to give fine grained control without coupling dependencies would be to have a global callback handler for asynchronous tasks. Users could use this to execute arbitrary code on completion (including waking the event loop) for any tasks, without coupling the asset and windowing crates.

[NthTensor]

I've always thought we should have something like web_bindgen_futures::spawn. This could add tasks to a queue when woken, and send a user event to the winit loop when adding the first task to the queue. The winit user event handler can then drain the queue of tasks and run them.

This has some nice properties:

• It can de-duplicate wakeups, so we don't send too many events to the winit loop.
• It is consistent with the existing behavior on web.
• The handler will never run indefinitely.