Repository navigation
perf(build): capture html film frames on several pages in parallel #25
Description
Problem
build captures html film frames one at a time on a single page: seek, wait until ready, screenshot, write to ffmpeg, then the next frame. A 65 s film takes about 3.5 min to build. The layout check (check, stills and build all run it) samples the film the same way, about 650 samples at 0.1 s steps, about 8 s per run.
Proposal
Open several pages of the same film and capture in parallel:
- Split the frame indexes across N pages (for example N = 4, configurable).
- Write frames to ffmpeg in order, buffering frames that arrive early, with a bound on the buffer.
- Do the same for the layout check's samples, keeping the sample order so the "two samples in a row" rule is unchanged.
Motion films draw inside their own player; parallel capture may also work there, but html films come first.
Done when
- The MP4 frames are identical to the sequential capture for the same film (compare frame hashes in a test).
- Build time of the same film before and after is measured and reported in the PR.
- Memory stays bounded when ffmpeg is slower than capture.
Activity
umiyosh commentedon Oct 25, 2026
Baseline before this change
Measured on master cb4dc37, macOS 26, Apple M4 Pro (14 cores, 48 GB), Node 25.1.0, 1080p30. Nothing else heavy ran at the same time.
checkstills(8 scenes)buildcheckstills(8 scenes)buildbuildincludes its own layout check (about 7-14 s), so frame capture plus encoding is about 4.6-5 min for a one-minute film, roughly 6-7 frames per second.How to repeat it: the two work dirs and the script are kept outside the repo (
bench.sh <repo> <label>runscheckx3,stillsx1 andbuildx2 per film, and writes frame hashes of each MP4). The WIF copy has one change from the published film: lit step numbers are dark, so it passes the contrast check added in #27.About the "identical frames" check below: two builds of the same film on master are already not bit-identical (PSNR about 60 dB, invisible; #29). Until #29 is fixed, compare the parallel build with the sequential one by PSNR against the same tolerance, not by exact hashes.