The depth-sort coordinator's state and the small helpers every part of it
uses.
The coordinator is split by concern — worker lifecycle
(worker-lifecycle.ts), ordering apply (ordering-apply.ts), the per-frame
scheduler (scheduler.ts), the offline-capture drain (capture.ts) and the
public DepthSortCoordinator class (../depth-sort-coordinator.ts) — over
TWO state objects with different lifetimes:
CoordinatorState: one per coordinator INSTANCE, i.e. per LuxarApp /
LuxarLayer. Everything that is about a host — its tracked nodes, its camera,
its frame wake-up, its capture suppression, the per-frame budget — lives
here, so two hosts on one page sort their own nodes against their own
camera and each wakes only its own render loop. Every module function that
touches host state takes it as its first argument.
workerHost: the ONE SortWorker the page shares, with its init
bookkeeping (epoch, starved-retry budget, status). Node registrations are
keyed by the render mesh's uuid, which is unique page-wide, and every sort
RPC resolves through its own promise back into the coordinator that
dispatched it, so sharing the worker needs no routing table. The host
tracks which coordinators are attached so a starved-init retry can wake —
and re-register the nodes of — every one of them, and so only the LAST
coordinator's dispose terminates the worker.
The docs on each field are the originals from the module-scoped coordinator.
The depth-sort coordinator's state and the small helpers every part of it uses.
The coordinator is split by concern — worker lifecycle (
worker-lifecycle.ts), ordering apply (ordering-apply.ts), the per-frame scheduler (scheduler.ts), the offline-capture drain (capture.ts) and the publicDepthSortCoordinatorclass (../depth-sort-coordinator.ts) — over TWO state objects with different lifetimes:The docs on each field are the originals from the module-scoped coordinator.