What

Tells authors in hyperframes check why motion blur is off.

• check reads the runtime's probe() for a page whose root asked for blur and reports motion_blur_off (warning, with a fix hint per reason code; the iframe-in-root hint now names <iframe>, <object>, <embed> and custom elements, which are all re-initialised when blur wraps the root, and a root mix-blend-mode has its own: move it to a child element, or drop motion blur), motion_blur_no_movers (info, when nothing moves fast enough to blur) and motion_blur_unverified (info, when the check browser has no html-in-canvas to decide with).
• It asks the runtime which root wants blur instead of reading attributes itself, so data-root="true" is honoured and the first composition's attribute is not mistaken for the runtime's choice. The finding is anchored (selector, data attributes, bounding box) on that same root, data-root="true" first and else the first composition, not on the first [data-composition-id] in the document.
• Right after probing it calls suspend() for the rest of its session. Its audits read plain DOM, so they no longer pay the roughly 10x slowdown of auditing a wrapped composition. It never sets the page's off switch, which would change the probe's answer.
• The console echo of the same message ([motion-blur] off: …) is dropped when a finding says it, so a finding is not shown twice; an unrelated console warning, and an error that only starts like the echo, are kept.

Why

Part 9 of 9 in the capture motion blur stack: #5875 → #5967 → #5968 → #5969 → #5970 → #5971 → #5990 → #5991 → #5992. It builds on #5991, which gives the runtime the reason codes, probe() and suspend() this reads.

The stack delivers opt-in capture motion blur for compositions, in Studio preview and in renders, drawn with Chrome's html-in-canvas. Blur turns itself off in several cases, and without this an author who asked for data-motion-blur="on" cannot tell from the check output.

Notes

• A script-set data-motion-blur is not supported: the attribute has to be in the HTML for the render-mode hint, and check reports only what the runtime decided.
• Cost of blur, from the stack's measurements: about 1.7x median render time for a blurred composition; compositions that are blocked or static cost nothing extra.
• The stack's documented limits (trails drawn over foreground elements; a halo on transparent movers; trails leaking past overflow:hidden; a 2D flip through scaleX = 0 blending as rotation; sub-pixel left steps in whole px; a fast child inside a parent that moved earlier not blurred; SVG elements not scanned; shadow DOM not scanned for backface; blurred preview updating at half rate; video preview about 2–3% darker; worker-count output differences; the scan leaving about one level of noise) are unchanged by this PR.

Testing

• checkMotionBlur.test.ts: each finding, its severity and fix hint (the widened iframe hint, root-blend-mode, and the accelerated-canvas hint, which now says the scan covers sub-compositions too and offers rendering that effect separately or flattening it out of the page, or dropping data-motion-blur on the composition), and the console-echo filter; checkMotionBlur.page.test.ts: the probe serialised into the page, which root it asks about, the suspend() right after the probe (and a runtime without suspend), the mover count, and a page that never opted in.
• checkBrowser.test.ts: a blur finding reaches the check output with its fix and its anchor, the anchor is the data-root="true" composition when a sub-composition comes first in the document, once when a second Chrome shares the sampling, the runtime's duplicate console line is dropped while unrelated warnings and look-alike errors stay, and nothing is added for a page that never opted in.
• check.test.ts still passes. bun run build and tsc --noEmit in cli pass; comment ratchet against feat(core,engine): report why blur is off, and what each render session did #5991's branch passes; every package is within its size budget.

🤖 Generated with Claude Code