Bevy 0.10 regression: very long startup if WinitSettings.unfocused_mode is set to UpdateMode::Reactive

[JayceFayne]

Bevy version

The release number or commit hash of the version you're using.

0.10/0.11/0.12/0.13

Relevant system information

Arch Linux

What you did

Running https://github.com/JayceFayne/bevy_regression
Pasting main.rs below:

use bevy::prelude::*;
use bevy::winit::WinitSettings;

fn main() {
    App::new()
        .insert_resource(WinitSettings::desktop_app())
        .add_plugins(DefaultPlugins.build())
        .run();
}

What went wrong

Takes very long to start

Additional information

Downgrading to 0.9 fixes the issue

[alice-i-cecile]

Could you give us a before / after tracing flamegraph? This might be due to the more involved system graph processing.

If that's the case, there are a number of things we can do to improve performance there, ranging from simple optimizations to caching the graph on disk.

See https://github.com/bevyengine/bevy/blob/main/docs/profiling.md for more info.

[alice-i-cecile]

Alternatively, given your reproduction this could just be a bug with how we / winit is handling that specific mode.

[JayceFayne]

Could you give us a before / after tracing flamegraph? This might be due to the more involved system graph processing.

If that's the case, there are a number of things we can do to improve performance there, ranging from simple optimizations to caching the graph on disk.

See https://github.com/bevyengine/bevy/blob/main/docs/profiling.md for more info.

Sure, I have traces for 0.9 and 0.10 in chrome tracing format, I'll attach them here. Since github does not allow me to upload json files I'll upload the rendered flamegraph.

My guess is that the 60 sec wait in 0.10 is because max_wait is set to 60 secs in unfocused mode for the desktop_app preset.

[alice-i-cecile]

FYI in the future you can bypass that limitation by using .zip files :) And agreed: that looks squarely like a windowing bug: let's see if we can't get this fixed for 0.10.1...

[geieredgar]

I've had a look at this and there are two parts that cause this behavior:

1. Wayland initializes the window with an unfocused state and only displays and focuses the window after a frame is submitted.
2. Pipelined rendering, which can cause app.update() to finish before the frame is submitted.

Tasks like running the prepare_windows system are spawned by a render thread to run on the main thread. If app.update() is already finished, those tasks have to wait until app.update() is called again.

With DefaultPlugins.build().disable::<PipelinedRenderingPlugin>() this issue does not appear, since the frame is submitted during the first app.update(). Winit sends a WindowEvent::Focused(false) event after creating the window, therefore the app is always updated at startup.

I think the most clean solution (from a task-stall-prevention perspective) would be to wake the main thread (by sending a user event through the winit event proxy) when a main-thread task is spawned by a render-thread, but this would require a lot of changes in a lot of unrelated places and probably hurt performance.

A more pragmatic solution could be to consider a Wayland window focused at creation (ignoring the WindowEvent::Focused(false) event unless we already received a WindowEvent::Focused(true) event for the same window). I can submit a PR for that if such a solution is acceptable.

[esensar]

Just checking in after seeing Mastodon post: https://fosstodon.org/@alice_i_cecile@mastodon.gamedev.place/111811705662087955

I can reproduce this issue on Wayland (Fedora 39, Sway WM) still, so I guess it is still a valid issue.