The client test failed about one full-suite run in twenty-five, always the same way: expect(fp.fills).toBeGreaterThan(40) receiving 31. fable hit it before touching anything on #29, flagged it as seed-dependent and correctly left it alone. It is not the seed.
What it actually is. The loop above the measurement advances the shared match until somebody dies — anywhere between five and two hundred seconds of play — and then the test counts how many fills the resulting view costs. The thing being measured was wherever that loop happened to leave the seat.
fills
run alone, 12 runs
154 - 236
the run that failed
31
A floor on a number nobody chose, over a view nobody fixed.
Two changes. The seat is now stood in a known place looking a known way before the frame is counted, so the walls in shot are the same every run; the few fills that still move are the bodies standing among them.
And the bound now says what run-batching means: fewer fills than half the columns the frame actually used, read off the client's own offscreen buffer, which the fake document now keeps a handle on.
That second part is not incidental. A constant cannot express this bound. The frame budget moves the world between 960 and 448 columns, so a per-column frame at the coarsest rung is 448 fills - which sits comfortably under any constant loose enough to survive the finest rung. My own first attempt used < 450 and would have let exactly that regression through; I only caught it by going looking for how the new bound could fail.
Proved both directions.
Forced the renderer to emit one run per column behind a flag: the new bound fails, as it must. The old constant would not have.
30 full-suite runs, 0 failures (was ~1 in 25).
304 tests, unchanged.
Also added: the same state drawn twice must cost the same. A frame whose cost wanders while nothing moves is a renderer bug, and it is the shape of thing the old bound was mistaking for flakiness.
The client test failed about one full-suite run in twenty-five, always the same way:
expect(fp.fills).toBeGreaterThan(40)receiving 31. fable hit it before touching anything on #29, flagged it as seed-dependent and correctly left it alone. It is not the seed.What it actually is. The loop above the measurement advances the shared match until somebody dies — anywhere between five and two hundred seconds of play — and then the test counts how many fills the resulting view costs. The thing being measured was wherever that loop happened to leave the seat.
A floor on a number nobody chose, over a view nobody fixed.
Two changes. The seat is now stood in a known place looking a known way before the frame is counted, so the walls in shot are the same every run; the few fills that still move are the bodies standing among them.
And the bound now says what run-batching means: fewer fills than half the columns the frame actually used, read off the client's own offscreen buffer, which the fake document now keeps a handle on.
That second part is not incidental. A constant cannot express this bound. The frame budget moves the world between 960 and 448 columns, so a per-column frame at the coarsest rung is 448 fills - which sits comfortably under any constant loose enough to survive the finest rung. My own first attempt used
< 450and would have let exactly that regression through; I only caught it by going looking for how the new bound could fail.Proved both directions.
Also added: the same state drawn twice must cost the same. A frame whose cost wanders while nothing moves is a renderer bug, and it is the shape of thing the old bound was mistaking for flakiness.