Restarting the discussion around reactivity

[viridia]

I've previously written a lot about Reactivity in Bevy, and I've been comparing my approach with the other third-party solutions out there.

For first-party reactivity, there's a fundamental design choice which, I think, has to be decided before anything else: Do we want the timing of reactions to be system-like or observer-like?

The question has to do with when reactions get run. It has nothing to do with fine-grained vs. coarse-grained, diffing vs. micro-reactions, and any of the other design choices we have discussed which can be decided later.

By "system-like" I mean that reactions run at a specific point in the Bevy schedule - generally somewhere in PostUpdate. All of my reactive PoCs use this approach, because it's the only approach I can figure out how to actually build.

By "observer-like" I mean that reactions are either immediate, or happen at the next command flush - that is, reactions happen all throughout the schedule in response to mutations, much like the way observers are triggered.

Both of these approaches have significant trade-offs:

System-like reactions:

• May cause a 1-frame delay if the data source is mutated in a later phase of the schedule, after reactions have run.
• May also cause delays if the reactions run in the main schedule, and the data source is updated in the fixed update schedule.
  • A potential workaround is to run the reactions in both the main and fixed update schedules, however this would entail additional overhead.
• Require polling of reactive data sources, even ones that haven't updated

Observer-like reactions:

• Require a solution to the diamond problem.
• Are hard to do without mutation observers, unless reactivity is limited to special wrapper types. And mutation observers are unlikely to appear any time soon, as they would entail performance losses.

What I'd like to get from this thread is arguments in favor or opposed to either of these approaches.

@cart @alice-i-cecile @JMS55

[MalekiRe]

I think it would be helpful to benchmark what the performance of system-like and observer-like reactions might look like. Requires polling of reactive data sources, even ones that haven't updated is not a problem if we can do 100,000 polls in 10 microseconds. We should try to be a little bit data-driven here, and if the reasons not to do system-like reactions are performance based, then we should have some numbers to base that on.

[JMS55]

I'm honestly fine with either. Whichever leads to better ergonomics, I'm not worried about performance.

System-driven is how I did it in bevy_dioxus, and it worked fine. You can also always let people re-add the system to different schedules if they want.

Observers are also an option, especially if bsn macro can implicitly add them. The difficulty is then cleaning them up when needed.

[akriegman]

I feel like system based reactivity is how you would solve the diamond problem anyways. Polling every reactive data source every frame is no worse than any other Changed<> query, right? So that feels like a design decision that we've already made.

[MalekiRe]

@viridia re: the diamond problem from the link you shared, i don’t think this is actually a fundamental issue for mutation observers if and only if we’re doing the observer layer through async reactivity.

the important difference is that, in async reactivity, we can know exactly when the async ui computations have reached quiescence. once node b and node c have both finished their async observer work, we can immediately propagate the mutation observer event for node d, with no frame delay. if node d then causes more recomputation, that’s still fine: it just becomes another propagation wave in the same async sync-point loop.

so the diamond case would look roughly like:

a changes
 ├─ async observer updates b
 └─ async observer updates c

b and c finish
 ↓
mutation observer for d runs immediately
 ↓
d recomputes from final b + final c

the key is that node d’s observer should not fire eagerly after only b updates, because c may still be in flight. instead, mutation observers would fire only after the current async observer wave has drained.

there are two possible ways to model this:

1. make a special observer/event wrapper, something like DiamondEvent<T>, which explicitly means “run after upstream async observer propagation settles.”
2. make this the default behavior for async mutation observers: they trigger only after all currently queued async observers have completed their current calculation wave.

i’m leaning toward option 2, because it makes mutation observers automatic rather than requiring users to manually identify diamond-shaped dependency graphs.

this fits naturally with the async bridge. right now the sync point exits once there is no immediate bridge work left:

pub fn async_world_sync_point<SyncPoint: 'static>(world: &mut World) {
    let sync_point = async_world_sync_point::<SyncPoint>
        .into_system_set()
        .intern();

    let async_world = world.get_resource::<StrongAsyncWorld>().unwrap().clone();
    let max_ticks = world.get_resource::<AsyncTickBudget>().unwrap().0;

    for _ in 0..max_ticks {
        if async_world.0.tick_sync_point(sync_point, world) == TickResult::NoWork {
            #[cfg(feature = "bevy_tasks")]
            bevy_tasks::cfg::web! {
                if {} else {
                    bevy_tasks::tick_global_task_pools_on_main_thread();
                }
            }

            if async_world.0.tick_sync_point(sync_point, world) == TickResult::NoWork {
                return;
            }
        }
    }
}

for ui, we could have a specialized version of this bridge, or a small hook in this one, where instead of immediately returning after no more async work is available, we first flush any queued async mutation observers. if those mutation observers cause more async work, the sync point keeps flowing until it reaches quiescence again.

pub fn async_ui_sync_point<SyncPoint: 'static>(world: &mut World) {
    let sync_point = async_world_sync_point::<SyncPoint>
        .into_system_set()
        .intern();

    let async_world = world.resource::<StrongAsyncWorld>().clone();
    let max_ticks = world.resource::<AsyncTickBudget>().0;

    for _ in 0..max_ticks {
        let async_work_ran = async_world.0.tick_sync_point(sync_point, world);

        // after each async wave, flush mutation observers whose watched
        // components changed during that wave.
        let observer_work_ran = flush_async_mutation_observers(world);

        if async_work_ran == TickResult::NoWork && !observer_work_ran {
            #[cfg(feature = "bevy_tasks")]
            bevy_tasks::tick_global_task_pools_on_main_thread();

            let async_work_ran = async_world.0.tick_sync_point(sync_point, world);
            let observer_work_ran = flush_async_mutation_observers(world);

            if async_work_ran == TickResult::NoWork && !observer_work_ran {
                return;
            }
        }
    }
}

then mutation observers become much less scary, because we can track them automatically.

for example, whenever an async mutation observer for component c is registered, we increment a tracker. when it is removed, we decrement it:

#[derive(Resource)]
pub struct MutationTracker<C: Component> {
    active_observer_count: AtomicUsize,
    _marker: PhantomData<C>,
}

then, after each async observer wave, if active_observer_count > 0, we check whether any watched c components changed and trigger the corresponding mutation observers.

fn flush_mutations<C: Component>(
    tracker: Res<MutationTracker<C>>,
    changed: Query<Entity, Changed<C>>,
    mut commands: Commands,
) {
    if tracker.active_observer_count.load(Ordering::Relaxed) == 0 {
        return;
    }

    for entity in &changed {
        commands.trigger_targets(AsyncMutation::<C>, entity);
    }
}

for very common components like transform, querying every changed component could become a foot-gun if there are 100k entities. but that’s true for mutation observer systems in general. we can optimize the common case by tracking only entities that actually have observers:

#[derive(Resource)]
pub struct MutationTracker<C: Component> {
    watched_entities: Vec<Entity>,
    _marker: PhantomData<C>,
}

then the flush only checks the watched entities rather than every changed c.

the reason i think this works particularly well here is that rust async gives us a useful property: our async computations are pollable state machines, and the bridge can know when the current wave of async ui work is idle. The instant the async wave is idle, we can propagate mutation observers. i don’t think javascript exposes the same kind of explicit quiescence point, because the event loop/microtask model doesn’t give user code the same direct view into whether all relevant async reactive computations have drained. that means this model could never have been explored in javascript, but we have an oppertunity to exploit it here in rust.

so the proposal is:

• async ui observers run during a sync-point wave
• changed components are tracked
• once the async wave reaches quiescence, mutation observers flush immediately
• mutation observers may enqueue more async work
• the sync point keeps looping until both async work and mutation observer work are idle
• this solves the diamond problem without a frame delay

i think this makes mutation observers not just manageable, but fully automatic and opt-in in async land, with no special casing or registering.

A proof of concept of async mutation observers that also solve the diamond problem is here: https://github.com/MalekiRe/bevy_malek_async/blob/master/examples/button_mutation.rs

[Diddykonga]

I suggest both paths, backed by the Push mechanism of Mutation Events that uses a EventComponentMessageTrigger (what is this Java 😅 ), and protected by Event de-duping.

This gives you Push-style:

Add a Mutate Event that fires from Mut<C>::deref_mut(), this would require an Deferred<ParallelCommandQueue> in the QueryState, for each Mut<C> to borrow &'s ParallelCommandQueue, which then gets output in apply/queue.

This prevents diamond problem for Push-style:

In apply_deferred before we apply commands, we do the mysterious Command Batching and de-dupe Events.
If the Event is de-duped you don't get redundant/excessive triggers, and at-least for Mutate<C> you don't lose any semantic value as the semantic meaning is: A Component that was changed/mutated 'at-least once.'

This gives you Pull-style, via Push-style:

Add a Entity Component Trigger that supports E: Message + Clone and clone it after running Observers to add it to the Messages.

Notes:

Query will want to only be set_apply_deferred() if it actually has 'Mutate-able' QueryData.

Instead of a ParallelCommandQueue from QueryState, we could maybe borrow it from the SystemState? or perhaps even better to change World's commands to Parallel, then borrow from World?