Skip to main content

Module wake

Module wake 

Source
Expand description

Reactive wake: schedule a follow-up tick whenever the current tick wrote typed properties that downstream consumers haven’t observed yet.

§Why this exists - “the dialog is slow”

The app only ticks on wakes (input events, or the window backend’s work_pending re-arm). Several state chains need one more tick after the tick that writes a PropertyStore cell before their effect is visible:

  • a click handler writes dialog_open -> reconcile_if_blocks mounts / despawns the <dialog> body on the next tick,
  • push_slider_to_signal mirrors a drag into its signal -> bound labels pull it on the next tick,
  • a derivation writes a derived cell that another consumer reads.

Without this system, that “next tick” never gets scheduled: the window backend re-arms only when AnimationsActive or FrameDirty says so, and a bare property write raises neither. The transition then sat parked until an unrelated wake - measured live on widget-garden: ~550 ms to open the dialog, ~4 s to close it (whenever the next incidental event happened to arrive).

The fix: at the end of every tick (A11ySync, before clear_property_store_dirty wipes the per-tick queue), raise AnimationsActive when the dirty queue is non-empty. The window backend’s work_pending check then re-arms a redraw, the follow-up tick runs within a frame, and the consumers converge. Quiescence is preserved: semantically-equal writes never enter the dirty queue, so a settled UI stops requesting ticks the moment no cell actually changes.

Functions§

request_tick_on_property_writes
Raise AnimationsActive when this tick ends with undrained property writes, so the write’s downstream consumers (if/for reconcilers, binding pulls, derivations-of-derivations) get their follow-up tick within one frame instead of waiting for the next unrelated input event.