Chrome captures: pixel, DPR and break captures take 8 cases at once (same bytes)

[thejackshelton]

What changed (packages/parity)

• New src/chrome-pool.ts:
  • CHROME_PAGES is one per core, at most 8.
  • inOrder(items, width, f) runs at most width items at a time and returns results in item order.
  • On a failure it starts nothing new, lets every started item end (so no page is mid-capture when the browser closes), and then throws the first failure in item order.
  • It is a leaf module, so the capture steps' regen inputs do not grow.
• cli/pixel-capture.ts, cli/dpr-capture.ts and cli/break-capture.ts take CHROME_PAGES cases at once in each DPR launch (research Parity: shard the determinism check per fixture #5 in speed-research.md §2.3).
  • Each case already had its own browser context (openPage or captureFixture), so cases share no state.
  • The zoom guard still runs before and after each launch, and the software-raster precondition is unchanged.
  • The pixel manifest keeps case order. Break captures are keyed by case, so finishing order changes nothing.
  • --recheck uses the same pool.

Tests

• New test/chrome-pool.test.ts: the most items running at once is exactly width; results come back in item order whatever order they finish in; the first failure in item order is thrown only after every started item ends; nothing starts after a failure; a bad width is refused.

What passed

• pnpm typecheck: pass.
• vitest run packages/parity/test/chrome-pool.test.ts: 2 passed.
• pnpm regen on the branch (job regen-speed-capture-regen): dpr-capture, break-capture and pixel-capture ran. Fixed point after 1 pass, 0 files changed, git status clean. Every PNG, DPR capture and break capture is byte-identical.

The Chrome loops per DPR, from the steps' own logs. Before is two earlier local regens (mq-r0, c2); after is this branch's regen. Both were under load.

loop	before (s per DPR)	after (s per DPR)
pixel-capture	35–51	17–33
dpr-capture	28–39	16–20
break-capture	26–36	11–12

The rest of each step's time is its fixture compiles, which #151 (native hash) cuts about 6×.

Note

The text stack (TXT1a and the later PRs on it) adds an authoredPrepare line inside these same loops, so it will need a small merge resolution when it catches up. The PM chose to take that cost now.

No tolerance, check, test or fixture changed.

🤖 Generated with Claude Code