[baldurpan]

Why

The second card on the home page took about 5 to 6 s to be fully visible, and its timing looked unrelated to Huginn. His flight does not reach that card until 5 to 6 s after load, so it usually started from a fallback 1.1 s after the previous pane, and its sweep could then run for up to 5 s.

What changed

• Sweep length: each sweep now lasts 0.6 to 1 s, where it used to last 1.6 to 5 s.
• First card: it still starts as Huginn reaches it.
• Second card: it always starts 0.6 s after the first (SECOND_CARD_FOLLOWS), so the two keep the same timing against him on every load.
• Safety timer: the timer for a stalled worker now runs from page load, at 8 s, and covers the case where no pane has started yet.

aurora.raven.ts is untouched, so his flight is the same as before. The sweep still runs in the direction he flies.

Timing

Production build on an Apple M1 Pro GPU, in headless Chromium. Times are seconds after page load.

Screen	Loads	Card 1 starts	Card 2 starts	Fully visible
1440×900	12	1.44–1.75	2.04–2.35	3.03–3.35
390×844	5	2.44–2.75	3.06–3.40	4.06–4.38

In the 6 desktop dev-server loads where I compared the two, the first card started 0.10 to 0.13 s before his body touched it.

Limits

• The second card starts on a fixed gap. He has not reached it yet at that point.
• The fallback entrance for pages without a fly-in is unchanged.
• The sweep can now overtake him, because it is shorter than the time he takes to cross a large box.

Checks

pnpm lint, pnpm format:check, pnpm check and pnpm build all pass. Timing was measured with a throwaway script; nothing was added to the repo's tests.

[craig-o-curtis]

Looks good, thanks. The cards now come in on time and the flight is untouched.

A few small things, none blocking:

• i === 2 && painted[1] assumes the order header, card 1, card 2. The raven code already treats index 1 as the card, but named constants (or a "each card follows the one before" rule) would keep this from breaking if a third card is added.
• Boxes he never reaches used to follow 1.1 s after the last one; now they wait for the end of the fly-in, with the 8 s timer as the backstop. Fine on the loads measured, just worth knowing.
• The commit message says the second card could take "over 10 s"; the description says 5 to 6 s.

[baldurpan]

Thanks @craig-o-curtis. On your three notes:

• Card order: agreed. It works for the two cards we have, so I've filed Card reveal order is hard-coded to two cards #15 rather than change the code after your approval.
• Boxes he never reaches: that's correct and intended. The old 1.1 s follow-on could start a box ahead of him, which made the timing inconsistent. On the measured loads, the title and intro were reached normally, and the second card uses the fixed gap.
• Commit message: you're right, "over 10 s" is wrong. That figure came from a slow software-rendered test, and the 5 to 6 s in the description is what was seen in a real browser. Fixing the commit would need a force-push, so the correction is in the merge commit instead.