Luxar Viewer API Documentation - v2026.10.19
    Preparing search index...

    Module rendering/depth-sort-coordinator/state

    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.

    NodeSortState
    SortWorkerHost
    CoordinatorState
    workerHost
    createCoordinatorState
    orderingApplyHooks
    syncSortElementLimit
    invalidateSortedNodeCommitStamps
    anyNodeWantsSorting
    liveBlendingMode
    isLiveOrderDependent
    releaseHeldDraw
    releaseWorkerNode
    clearSortPose