Expand description

The loop abstraction for driving state changes. It binds to the state tracker in state::Application, and actually gets driven by a driver in the driver module.


If we performed updates in a tight loop, the state tracker would have been all we need.

loop { event = current_event() outcome = update_state(event) io.apply(outcome) }

This is enough to process all events, and keep the window always in sync with the current state.

However, we’re trying to be conservative, and not waste time performing updates that don’t change state, so we have to react to events that end up influencing the state.

One complication from that is that animation steps are not a response to events coming from the owner of the loop, but are needed by the loop itself.

This is where the rest of bugs hide: too few scheduled wakeups mean missed updates and wrong visible state. Too many wakeups can slow down the process, or make animation jittery. The loop iteration is kept as a pure function to stay testable.

Modules

This drives the loop from the loop module.

Structs

State 🔒

This keeps the state of the tracker loop between iterations

Traits

Contains and calculates the intenal state of the actor.

Carries the incoming data to affect the actor state, plus an event to help schedule timed events.

The externally observable state of the actor.

Functions

A single iteration of the loop, updating its persistent state.