Per-tick bound inside flushRenderTicks — it caps the kick evaluate
and the confirmation wait individually, and each is additionally clamped to
whatever is left of FLUSH_BUDGET_MS.
This workstation software-renders at ~4.4 animation frames/s while a scene
loads (measured: 123 rAF callbacks and 246 renderer.render() calls over a
28 s window, i.e. ~230 ms per frame and ~114 ms per tick), and that is not
the worst case — it was measured on an otherwise IDLE box with this spec
alone in flight, so a busier machine can only be slower. What starves the
CDP round trip this wait reports over is a backlog of already-queued
main-thread work (#1651); the OPFS timeout: set(...) exceeded 10000ms
writes arriving in the same window are the producer that measurably moved
the needle, and #1647 is what addresses them. 3 s is ~26x the measured
per-tick cost, which buys headroom for a slower box cheaply — and, unlike
before, buys it without multiplying: the aggregate budget below is what
bounds the flush.
Per-tick bound inside flushRenderTicks — it caps the kick evaluate and the confirmation wait individually, and each is additionally clamped to whatever is left of FLUSH_BUDGET_MS.
This workstation software-renders at ~4.4 animation frames/s while a scene loads (measured: 123 rAF callbacks and 246
renderer.render()calls over a 28 s window, i.e. ~230 ms per frame and ~114 ms per tick), and that is not the worst case — it was measured on an otherwise IDLE box with this spec alone in flight, so a busier machine can only be slower. What starves the CDP round trip this wait reports over is a backlog of already-queued main-thread work (#1651); theOPFS timeout: set(...) exceeded 10000mswrites arriving in the same window are the producer that measurably moved the needle, and #1647 is what addresses them. 3 s is ~26x the measured per-tick cost, which buys headroom for a slower box cheaply — and, unlike before, buys it without multiplying: the aggregate budget below is what bounds the flush.