Ticks asked for.
Ticks confirmed against the renderer's own counter.
The counter value the flush started from, or null when that probe went
unanswered — in which case no baseline exists and a zero landed cannot
be judged either way (reportFlushVerdict says so and moves on).
How many kicks the page answered / rejected / never answered.
How many confirmation waits actually ran (≤ requested).
Wall-clock the whole call spent, baseline probe included.
The aggregate budget this call was given, in ms — FLUSH_BUDGET_MS unless the call site passed its own. Carried so a message about the budget quotes the bound that actually applied.
True when the aggregate budget is what ended the loop — either because nothing was left to dispatch the next kick/wait with, or because the wait that timed out had been CLAMPED down to the budget remainder.
The clamped bound, in ms, of a confirmation wait that timed out because the
budget remainder — not TICK_TIMEOUT_MS — was what bounded it;
null when no wait ended that way. Reported so a shortfall message cannot
claim every wait got the full per-tick bound.
What a flushRenderTicks call actually achieved.