OptionalonOptionalonOptionalownerWho staged this ordering. Opaque here; the per-owner teardown sweep (cancelAllSortedIndexOrderingApplies with an owner) filters on it, so one depth-sort coordinator's dataset switch or dispose never abandons another coordinator's streams on the same page.
Optionalrequest"Request one more frame", invoked from a slice's upload acknowledgement so a drained-but-idle stream resumes the instant the mesh is actually drawn again (issue #715 resume gap: the coordinator deliberately does NOT request a render on a stall, so a camera coming to rest exactly as a culled node becomes drawable would otherwise freeze the stream mid-drain). A consumed slice means the mesh WAS drawn, so this drives the next pump precisely — no spin while hidden, because a mesh that is never drawn never fires the acknowledgement. Per ordering rather than module-wide so it wakes the render loop of the host that owns the mesh.
OptionalbypassWhen it returns true, applyNextSortedIndexChunk advances past the
#715 upload-acknowledgement back-pressure. The depth-sort coordinator's
offline-capture drain (resortForCapture) turns it on for its own
streams: that drain never draws, so the ack that releases the stall can
never fire and a multi-slice stream (>1 slice, e.g. a 3M-element node)
would wedge the drain until its timeout on every captured frame. The
stall exists only to bound the per-DRAWN-frame upload for interactive
smoothness; offline, folding the slices into one upload on the capture's
own render is exactly acceptable, and the range-union discipline keeps
the pending span contiguous and current (a superset upload is correct,
never stale).
Lifecycle hooks for one staged ordering (the depth-sort coordinator wires these to its 'Depth Sort' profiler session so the pass spans the whole dispatch→applied lifecycle — issue #713). EXACTLY ONE fires per accepted ordering:
onAppliedafter THREE renders the geometry with its selected buffer (post-upload/draw acknowledgement), oronAbandonedwhen it is dropped before that render (superseded as a held pending or selected slot, identity-written over, geometry disposed, node released, dataset switched, app disposed). Never both, never neither. They fire ONLY when writeSortedIndexOrdering accepts the ordering (returns > 0); a rejected write leaves session ownership with the caller.