WASM perf regression: App updates triggered by input events

[Azorlogh]

Bevy version

• Original: bevy-0.13.2
• Current: bevy-0.14.0-rc.3

Relevant system information

Please include:

• Rust version: 0.78.0
• Firefox 126.0.1
• Linux/x11
• Nvidia proprietary 550.90.07

What's performing poorly?

I discovered that after updating my wasm app to 0.14, it feels very sluggish.

Here is a minimal reproducible example:
When idle the square moves in a circle. Moving the cursor or keeping a key pressed, the square will begin to skip around.

use bevy::{prelude::*, sprite::MaterialMesh2dBundle};

fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .insert_resource(A(0))
        .add_systems(Startup, setup)
        .add_systems(Update, run)
        .run();
}

fn setup(
    mut commands: Commands,
    mut meshes: ResMut<Assets<Mesh>>,
    mut materials: ResMut<Assets<ColorMaterial>>,
) {
    commands.spawn(Camera2dBundle::default());
    commands.spawn((
        MaterialMesh2dBundle {
            mesh: meshes.add(Rectangle::default()).into(),
            transform: Transform::default().with_scale(Vec3::splat(128.)),
            material: materials.add(Color::WHITE),
            ..default()
        },
        Angle(0),
    ));
}

#[derive(Debug, Component)]
struct Angle(u8);

#[derive(Resource)]
struct A(u128);

fn run(mut q_angle: Query<(&mut Angle, &mut Transform)>, mut a: ResMut<A>) {
    // do something slow
    for i in 0..10_000_000 {
        a.0 += i * i;
    }

    for (mut angle, mut transform) in &mut q_angle {
        angle.0 = (angle.0 + 1) % 8;
        transform.translation =
            (Vec2::from_angle(angle.0 as f32 / 8.0 * std::f32::consts::TAU) * 250.0).extend(0.0);
    }
}

Additional information

We can see that after 0.14, updates are triggered by pointermove events. Painting only happens about once every 3 frames as a result. The same happens when keeping a key pressed.

• Before:
  

• After:
  

[alice-i-cecile]

To me it looks like when should_update is true we are now calling run_app_update directly here
Where as before, we used to only request a redraw

By @tychedelia on Discord.

[beoboo]

My 2c here: the loop is very different from before, and it's more oriented to something like:

• wait for NewEvents (triggered by window, user or device events or a timeout between frames)
• execute all events in the middle
• run AboutToWait

The loop is also not sensitive to the specific event type (e.g., it treats mouse events in the same manner as window resize ones). For each event that wakes up the loop, it updates the app.

It could be more selective, and define which event triggers what: for example, mouse events could reasonably trigger request redraws only, and request redraws could trigger app updates. The only big difference from before is that app updates need to be executed inside AboutToWait, since this also changes the UpdateMode that sets the new wait duration for the next frame, and that needs to happen in the last event of the cycle. (it's not only that, but this gives a rough idea).