ECS Change Events

[cart]

The ability to query added/removed/changed components would enable a whole class of optimizations (ex: only updating Transforms when a Translation/Rotation/Scale component changes). It would also make a number of ui patterns easier (only run this when UiComponent state is modified).

[cart]

Component modification tracking was added here: 31d00ad

Added + removed events would still be useful for some things, but Changed<T> provides most of the utility we needed from this feature.

[cart]

Just added Added<T> queries here: a695304

Removed queries need to be a little different because archetypes no longer store the removed entities. I think users will want an api that builds on top of the existing query system, so i'm envisioning something like this:

fn system(query: Query<(&A, &mut B)>) {
  // returns entities that (1) matched the query and (2) removed B last update
  for entity in query.removed::<A>() {
  }
}

or this:

fn system(query: Query<(&A, &mut B)>) {
  // returns entities that matched the query and removed A and B last update 
  for entity in query.removed() {
  }
}

[cart]

There is also an issue with how we handle all change events:

schedule.run()
  system_1: Query<Changed<T>>
  system_2: Query<&mut T>, modifies T
  system_3: Query<Changed<T>>
  world.clear_trackers()

system_1 wants to run whenever T changes, but it will not run when system_2 modifies T because world.clear_trackers() runs at the end of the schedule.
system_3 receives the change state because it comes after system_2 and before world.clear_trackers()

I can think of two solutions to this problem:

• leave it as is. if you want to consume change events, add the system after the modifying systems.
• double buffer modified events, so each system will always have a chance to receive the change (much like how Events currently works). this case is a bit more complicated because we dont have EventReaders here.

[cart]

i gave "system order-independent tracking" a little more thought:

ideas

• double buffering
  • Lots of state (entities moving archetypes / getting removed) that makes this both complex and potentially expensive. for an old modified buffer [false true false] and a new modified buffer [true false false], buffer[0] could correspond to different entities
    • would probably need to keep two lists of entities (last frame / current frame) and do a hash lookup to see if the "old" buffer's entities are still valid
• Stateful queries w/ modified generations
  • no world.clear(), all tracking queries are stateful
  • each query maintains a last_seen_generation: HashMap<Entity, ModifiedGeneration>,
  • Mut pointers either directly increment the generation or set a bool like they do today (which then after system execution results in an increment)
  • if we track both "modified_generation" and "modified_this_update", we could keep the current "cheap but order dependent" tracking and add "expensive but order independent" tracking, at the cost of some additional bookkeeping overhead. (we would need to write to two places instead of one, and archetype moves / inserts would need to copy 2x the amount of change metadata)
• for systems with a Changed query, identify systems with &mut T after and track changes that occur
  • instead of Mut { modified: &mut bool }, we would have Mut { modified: &mut [bool] }
  • potential to be very expensive
• no automatic clears
  • puts the burden of clearing on the user. could result in bad cross system interactions (what if two systems clear ... what happens when someone else's library clears something you need). if clears were per-system, this would be reasonable, but if we can make them per system we could just do double buffering (i think its the same problem)

in general i consider this to be a hard problem that doesnt need solving right now. the optimizations we care about right now should all play nicely with the current setup. and users can design their code around this. i cant think of a way to make order independence work without adding some level of statefulness somewhere (which translates to adding overhead).

I'll open an new issue for order independent change tracking, but i think that solution should hinge on:

1. allowing the current "cheap" form of tracking
2. now slowing down normal non-tracked system

[cart]

The last part of this issue (now that we've tabled order-independence) is component removal tracking.

Rather than storing component removals in archetypes and adding removal queries (as suggested above), I think it might be easier (both to implement and understand) to just store component removals directly in world. Removals could then be iterated using: world.iter_removed::<T>(). bevy_ecs Queries could mirror that interface, which would be safe because removals cannot happen without exclusive world access.

world.clear_trackers() would still clear removals

[cart]

f82af10 adds component removal tracking, which means we can finally close this!