motion: 5-second rule budget cannot cover screenshot + decode + pixelmatch — rule times out whenever an image exists

[wittjeff]

Summary

The motion rule's timeOut: 5 budget cannot cover the work the rule does, so in practice the rule times out whenever it has an initial image to compare against — which means it never produces a verdict at all.

Evidence

Checking our scan fleet's stored reports (all scans that ran the testaro tool):

• 82 scans ran the testaro tool.
• 78 had no catalog image (no imageColor), so motion was prevented with "Initial image missing" — expected.
• In the 4 scans that did have a catalog image, motion was prevented by timeout — all 4 of 4.
• Across the fleet's entire history, motion has never completed a comparison (zero verdicts, pass or fail).

Why the budget can't fit

The per-rule time limit races only the reporter (tests/testaro.js), so launch/navigation is excluded — that part is fine. But inside the budget, motion must:

1. Take a full-page screenshot via shoot(), whose own internal page.screenshot timeout is applyMultiplier(4000) — 4 of the 5 seconds, scaled by the same multiplier as the rule budget, so the ratio never improves.
2. Decode two full-page PNGs with PNG.sync.read (a full-page shot of a long page is easily 10k+ CSS px tall — tens of megapixels).
3. Run pixelmatch over every pixel.

Steps 2–3 alone routinely exceed the ~1 second that remains after a normal screenshot, and a screenshot that uses most of its 4-second allowance leaves nothing. The arithmetic makes the timeout close to deterministic on real pages; our 4-of-4 is consistent with that.

Suggested remedies (can combine)

1. Raise motion's timeOut to something that fits the work, e.g. 20–30 (there is precedent: another rule already uses timeOut: 30). One-line change; I'm happy to PR it.
2. Longer-term: exclude the screenshot from the raced budget (take the shot, then start the timer), or compare on downscaled images / a capped page height to bound decode+compare cost.

Related but independent: #51 / PR #75 keep images[0] CSS-scale so this rule's comparison stays valid under imageScale; nothing there changes the cost profile described here.

[jrpool]

@wittjeff: Increasing the time limit for the initial image capture or allowing subsequent actions to begin while the image is being captured seems worth considering. But the image occupies a substantial part of the report, and it may make sense to consider whether making images on the fly of catalog elements that violate rules, instead of a whole-page image, would be more compact and would simplify the task of consumers that want to render images of offending elements for users. The current motion rule relies on a full-page image existing, but making that image could be an option that a job would exercise when it includes the testaro motion rule (or otherwise needs an initial page image), and the motion module could dispose of both images after use. Your other idea, about capturing only part of a page, seems also worth considering. It could be the top, or several sampled areas.