Repository navigation
Conversation
…ntrol In Chromium, the animator's busy-window proof also checks that the spring sits on its curve from its start: the median of each frame's stamp, less the spring's start and its time on the curve, had to be under 20 ms. A loaded runner stamps screencast frames late, and that median moves by the stamps' latency: it read 21.97 ms on a 4-worker pin while the spring's drift against the control held at 3.9 ms (bound 12). Each frame's time now comes from the control instead of its stamp: the control's start, read from its animation, plus its time since then, which its position gives within the cycle the stamp falls in. The spring's median offset from its curve at those times keeps the 20 ms bound. The stamped median is still recorded.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
meta-cla
Bot
added
the
CLA Signed
|
AI review status for this pull request.
|
PR Analysis Report
Generated by PR Enrichment workflow | View current CI run |
![astracat-bot[bot]](https://avatars.githubusercontent.com/in/4796231?s=60&v=4){kind=small}
There was a problem hiding this comment.
Looks good to approve: the Chromium check now takes frame times from the control animation, so a stamp delay under 400 ms no longer moves the result, and the check still fails a spring whose reported start is off. One optional note sits inline on the comment that keeps the check Chromium-only.
[Automated review]
| // not this one. Only Chromium stamps frames on the page's clock, so only | ||
| // there does a stamp tell the cycle. |
There was a problem hiding this comment.
Optional, non-blocking: this reason may be stronger than needed. frames.ts rebases WebKit's monotonic stamps onto the wall clock "so both engines share the page's timeline", and the cycle choice here only needs a stamp within 400 ms of the page clock. In local WebKit runs of this test, fromStart read about -4 to -5 ms. If that holds on the WebKit CI job, the comment could say that the old 20 ms stamped check needed Chromium, not the cycle choice. A follow-up could also extend the bound to WebKit.
Maintainer impact
The animator's browser proof "a spring keeps advancing every frame through a 1 s main-thread block, on its curve" fails on a loaded runner in Chromium. Its last check, that the spring sits on its curve from its start, took the median of each frame's screencast stamp less the spring's start and its time on the curve, and required it under 20 ms. A loaded runner stamps frames late, and that median moves by the stamps' latency. A sweep of
mainon a 2-core pin with 4 workers read 21.97 ms in 1 of 5 runs, while the spring's drift against the harness's control held at 3.9 ms (bound 12) and the faster-spring check held.Intended invariant
In Chromium, the proof still checks that the spring is on its analytic curve from the start it reports, to within 20 ms at the median. The drift against the control, the faster-spring check and the busy-window verdict are unchanged.
Change
Each frame's time now comes from the control instead of the frame's stamp. The control moves 240 px out and back every 800 ms, linearly, on the compositor, and the test reads its start from its animation. On each frame, the control's position gives its time within a cycle, and the frame's stamp only picks which cycle, so a stamp may run late by up to 400 ms without changing the result. The spring's median offset from its curve at those times keeps the 20 ms bound. The stamped median is still recorded beside it. Only Chromium stamps frames on the page's clock, so the check stays Chromium-only.
controlClock.tsexports its cycle length for this.Evidence
main(median 31.2–32.5 ms). On the 2-core pin with 4 workers,main's check fails 11 of 20 (medians 22.8–34.9 ms) while the drift against the control holds (2.7–5.6 ms).responsescaled by 0.9, the median against the control reads −51 to −61 ms (drift 60–95 ms); scaled by 1.1, it reads +47 to +49 ms (drift 73–75 ms). Both fail, at the drift check first and at this check too.Status at this head: every gate has finished. Build, type check, strict lint (
ASTRYX_STRICT_LINT=1 pnpm lint), the comment-provenance baseline check,check:changesetsandcheck:repopass, and changeset coverage reports that nothing here ships.test:uipasses (17,968). The node suites fail only the twocache.test.mjslock cases that fail onmain. The whole animator spec passes ×3 in Chromium on the 2-core pin at 1 worker (54) and at 4 workers (54), ×10 under the CI WebKit job's command (140), and at 3 CPUs with 1 and 16 workers (14 each). Outside these profiles, unpinned on a busier box, the spec's case "a retarget made before the page can read a call's start begins where the screen shows the element" failed in Chromium both onmainand with this change, its frames reading x = 0: a late start onmainthat a separate fix covers, and a case this change does not touch.Scope
Testing
The stamp-delay seam used for the reproduction (local only, not committed), in
blockedRun:The off-curve spring (local only): the animated spring's
responsescaled by 0.9 or 1.1 while the proof judges it against the unscaled curve.