Interface TimingMetadata

Number of chunks loaded

Cache hits (L1 + L2)

Cache misses (network fetches)

Points visible/loaded

Segments visible/loaded

Splats visible/loaded

Triangles visible/loaded (mesh) — the fourth per-type counter, so a mesh row gets the same formatted, tooltipped tag as its siblings AND sums across same-update sessions. Mesh used to ride as a free-text info: "N faces" string, which is last-write on merge: an aggregated row covering three mesh layers reported only the last one's face count.

Elements processed by a geometry-agnostic pass (the depth-sort rows, which sort points, line segments, Gaussian splats or mesh triangles through one machinery) — kept separate from the per-type counts above so the monitor never labels 3.0K sorted POINTS as "splats".

Whether this operation was skipped

Reason for skipping

Custom string data

Depth-sort split (set on 'Depth Sort' passes only): ms inside the backend sort_splats_by_depth call on the worker. LAST-WRITE on merge (not in SUMMED_METADATA_KEYS) — these are per-sort latencies of the most recent sort, not counters; summing across merged sessions would be meaningless.

Depth-sort split: worker-side overhead around the kernel (= workerMs − kernelMs; sortNode body minus backend call: registry lookup + ordering allocation). Last-write on merge, see kernelMs.

Depth-sort split: dispatch→resolve round-trip minus the worker-side time (= roundTripMs − workerMs; Comlink RPC + structured-clone + event-loop queueing on both sides). Last-write on merge, see kernelMs.

Depth-sort split: resolve→applied duration — how long the chunked ordering apply took from worker resolve until its buffer was drawn (issue #713). The pass's total lastMs is dispatch→applied; kernelMs+boundaryMs+queueMs cover dispatch→resolve, applyMs the rest. Last-write on merge, see kernelMs.