[miguel-heygen]

What

Page setTimeout and setInterval now keep the film's schedule at every worker count, not only with one worker.

Why

#7362 runs page timers on film time during a render. A timer a page starts in its first animation frame is scheduled from that frame's time. With one worker, the first frame a page renders is the film's frame 0, so the schedule starts at 0. With several workers, each worker's page starts at its own first frame. A worker whose first frame is at 133 ms schedules a 100 ms chain from 133 ms, so its ticks land at 233, 333 and so on, a step behind the film for the rest of that worker's frames.

The timers-on-film-time regression film shows it. Its bars match the reference video on every frame at 1 worker, and on 33 of 90 frames they are a step short at 6 workers.

How

seekToTime in the virtual-time shim is now a named function. On the seek that starts rendering, if the target is past 0, it first plays the film's frame 0: it fires timers due by 0 and flushes animation frames at 0. Then it seeks to the target as before, which fires every timer due in between, in due order. A one-worker render is unchanged, because its first seek is already 0.

Tests

New in fileServer-virtualTimers.test.ts: "keeps the film's timer schedule on a worker whose first frame is past the start". A page starts a 100 ms chain in its first animation frame, and the first seek is to frame 4 (133 ms).

fails without the fix: packages/producer/src/services/fileServer-virtualTimers.test.ts › "virtual-time shim timers" › "keeps the film's timer schedule on a worker whose first frame is past the start" (on main: [] instead of [100] at 133 ms, because the chain was scheduled from 133 ms).

Rendered the timers-on-film-time film from this branch on Linux and compared every bar's width on every frame with the film's reference video:

	1 worker	3 workers	6 workers
main	0 of 90 differ (rendered with the 0.9.21 release, same shim)	not run	33 of 90 differ
this branch	not rerun (first seek is 0, path unchanged)	0 of 90	0 of 90

Also run:

• fileServer-virtualTimers.test.ts, fileServer-seededRandom.test.ts and fileServer.test.ts: 77 of 77, three runs in a row.
• Producer typecheck, oxfmt and the comment ratchet.

Size

About 25 lines in one function and one test.

[heygengenesis]

Request changes at 68b5cd2f. The only blocker is in the PR description. The fix itself looks correct.

Blocker: the fails without the fix: line doesn't name a test. The line has to name the test that fails without the fix. Line 19 of the body only describes the symptom: "on main the chain has not fired at 133 ms ([], expected [100])…". The test's name is in the sentence before it, not on the line. Putting it on the line clears this:

fails without the fix: packages/producer/src/services/fileServer-virtualTimers.test.ts › "virtual-time shim timers" › "keeps the film's timer schedule on a worker whose first frame is past the start" (on main: [] instead of [100] at 133 ms)

Editing only the body doesn't change the head, so I'll re-review at this same SHA.

What I verified:

• At the head, fileServer-virtualTimers.test.ts, fileServer-seededRandom.test.ts and fileServer.test.ts give 77 pass, 0 fail.
• With fileServer.ts taken from main (b87a01f6a), the new test fails (8 pass, 1 fail). The other tests in that file still pass.

Code review found no other issues:

• The extra seekToTime(0) happens only on the first seek after __renderReady, because rendering is never reset. The inner call sees rendering === true, so it can't recurse again.
• A one-worker render's first seek is 0, so its path is unchanged.
• With seeding on, the frame-0 pass runs reseedRngFromTime(0) before the target's reseed. That matches the sequence a one-worker render sees.
• Timers due between 0 and the target still fire in due order when the target seek runs fireDueTimers.
• The seekToTimeReseedCall indent change only follows the function moving out of the object literal.

Note, not blocking: the frame-0 pass also runs the page's frame-0 requestAnimationFrame callbacks on every worker past frame 0. That's the intent, and it matches a one-worker render, but it's a small cost per chunk.

CI was still running when I reviewed: CI, CodeQL, regression and Windows render verification. preview-regression, Player perf, PR captures and Comments passed.

[github-actions]

Edit accuracy: accurate 267 (base branch 267), smooth 106 of those

The gate passes.
Smoothness is reported in the artifact, not gated. A case fails only if it fails 2 of 3 runs.

Quarantined, measured but not gated (8)

• seqplainkeys-none-center-r0-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-center-r0-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-center-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-pct-r0-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-pct-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-px-r0-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-px-r30-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-px-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run

[heygengenesis]

Approve at 68b5cd2f. The blocker is resolved.

• The fails without the fix: line now names fileServer-virtualTimers.test.ts › "virtual-time shim timers" › "keeps the film's timer schedule on a worker whose first frame is past the start". I reproduced this earlier: with main's fileServer.ts that test fails (8 pass, 1 fail). At the head the three fileServer* suites give 77 pass, 0 fail.
• The head is unchanged since my last review, so the code findings there still apply.
• Actions at this head: CI, CodeQL, regression, preview-regression, Windows render verification, Player perf, PR captures and Comments all passed. The body edit started a second Windows render verification run, which was still running when I approved. The first run on this head passed.