You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
The display timing engine costs 939 B on every first paint for an output read through one flag #673
The display engine splits into two layers with very different economics, measured separately:
The verdict ladder (the reveal gate, earned-success, first-post-edit-blur stickiness, the own-path error filter, the four show* projections and the displayState enum they derive from): 258 B, with showErrors read 51 times. The best byte-per-mile in the whole audit. Not a candidate for anything.
The timing layer (DEFAULT_TIMINGS, FOCUS_OUT_GRACE, PENDING_LIVENESS_MS, withLiveness, nearestReviewAt, the rearm forward-progress guard, the MAX_DELAY clamp, the visibilitychange listener, the retained DisplayMachine map, and the fieldValidatingSince / fieldTransformingSince anchor maps with their inc/dec/clear/migrate bookkeeping): 939 B, the largest single number in the audit, on every consumer's first paint. Its entire consumer-visible output is showPending, read 6 times in the only real app.
An opt-in is the wrong answer and is not what this proposes. Anti-flash is a hard-won behaviour that every consumer should get without reaching for a knob, and a knob nobody turns is worse than the bytes.
The shape worth investigating is an automatic lazy chunk. A form with no async validator and no async transform can never produce a pending state, so the timing machinery could dynamic-import on the first async open. Nobody configures anything, and the bytes leave the eager path for apps that never do async work.
Unmeasured, and that is the point of this issue. Two things need to be established before this is worth planning:
How much of the 939 B is machinery versus wiring. A lazy arm saves runtime work, not bytes, unless it is a real chunk boundary, and the eager closure currently reports async: 0 because a prior pass deleted the last one.
What the first pending state costs when the chunk has to load. Pending states are already asynchronous by definition, so a tick of latency is plausibly free, but that needs measuring rather than assuming.
If (1) comes back saying most of the 939 B is wiring that cannot leave, close this. The measurement is the deliverable.
Found in the 2026-09-18 feature audit (main@b4a64ef9, eager baseline 33,204 B gz). Every byte figure is a measured ablation, not an estimate.
Activity