Horizontal-band ghosting in transparent renders: content duplicated at exactly renderHeight/4 offsets; persists from 0.6.101/Chrome 131 through 0.7.82/Chrome 152

[hokaso]

Describe the bug

When rendering certain HTML compositions to transparent video (--format mov, alpha), the output contains ghost copies of page content duplicated vertically at an offset of exactly renderHeight / 4 (e.g. 286 px bands for a 1144 px-high render). Static, non-animated DOM elements are duplicated as well, so this is not an animation/timeline issue. The defect reproduces deterministically on the same composition and has survived a major engine upgrade.

Evidence highlights:

• Ghost copies sit at a vertical offset of exactly one band height (renderHeight/4); cross-correlation between the original band and the ghost band is ~99.6% — whole-band content displacement, not motion blur or timeline error.
• A frame-differencing metric over 959 frames scores 65.8% dirty frames on 0.6.101/Chrome 131 and 78.8% on 0.7.82/Chrome 152 (absolute numbers not directly comparable across engines because 0.7.82 also renders the composition's background grid differently, adding a new vertical-stripe component; the band-duplication signature itself is unchanged). A control band shows ~0.5%, so the signal is structural.
• Static <div>/SVG rects with no animation are duplicated too. Trigger appears to be structural (which elements/paints the page contains), not load-related: sibling compositions with far more primitives render clean.

Link to reproduction

Self-contained single-HTML composition available on request (contains our channel content, so not published in a public repo; we can also run candidate builds on our side)

Steps to reproduce

1. Single-page composition: one GSAP paused timeline registered on window.__timelines, seek-driven frame capture (standard hyperframes particle pattern). One <template> root, no external assets.
2. Render: hyperframes render <projDir> -o out.mov --format mov --fps 60 --quality high --workers 8 --no-browser-gpu
3. Inspect the alpha channel of the output frames (e.g. extract frame 300) — ghost copies of page content appear vertically offset by exactly renderHeight/4.

Expected behavior

Each piece of page content appears exactly once per frame; the alpha channel contains no duplicated bands.

Actual behavior

Ghost copies of page content appear in the alpha channel, duplicated vertically at exactly renderHeight/4 offsets. The same annotated text row appears twice, one band apart, in both frames below. Reproduces on both engine generations.

Alpha masks of frame 300 from both engines are attached below (order-independent identification): the frame WITHOUT wide vertical bars is 0.6.101/Chrome 131; the frame WITH the additional wide translucent vertical bars is 0.7.82/Chrome 152 — that stripe component is new in 0.7.82 (background grid lines rendered as wide bars), while the band-duplication signature itself is unchanged across both.

Environment

run A: hyperframes CLI/producer 0.6.101, chrome-headless-shell 131.0.6778.85 (linux)
run B: hyperframes CLI/producer 0.7.82, chrome-headless-shell 152.0.7928.2 (linux)
host: Linux x86_64, software GL (SwiftShader), no GPU flags
command: hyperframes render <projDir> -o out.mov --format mov --fps 60 --quality high --workers 8 --no-browser-gpu

Additional context

Things we already ruled out / tried:

• Injecting Chromium compositor flags (--disable-partial-raster, large raster tiles, --disable-checker-imaging): no effect on the dirty-frame rate, so the naive "partial raster invalidation" hypothesis appears falsified — the defect seems to live in the capture path rather than in cc tile reuse. (Side note: buildChromeArgs is a hard-coded array with no extra-args injection point; we had to wrap the chrome binary to test this. An escape hatch like PRODUCER_EXTRA_CHROME_ARGS would help future debugging.)
• Merging the affected SVG line primitives into a single path makes the ghosting disappear on that composition — we use this as a content-side authoring workaround, but it is guidance, not a fix.

Questions:

1. Is the frame-capture path expected to reuse any per-band/tile buffers between seek captures in screenshot mode?
2. Any known invalidation issue where band N's content can be re-presented at band N±1?
3. If you have a debug flag to force full-page re-raster per captured frame, we can A/B it immediately.

[miguel-heygen]

Thanks for the unusually good report. Update, plus one ask.

We tried a fix, it was wrong, we closed it

#3062 proposed applying Chrome's --disable-gpu-compositing to software screenshot captures, on the theory that this is the same SwiftShader stale-layer bug as #2550. We closed it. Two reasons:

1. The screenshot path does not retain stale layers. We re-rendered the composition from the Non-deterministic render: sub-compositions double-mount when video metadata loads after capture starts (timeline_rebind_after_media_metadata) #2550 regression fixture in software screenshot mode. The frames where the ghost reliably appears on the unfixed BeginFrame path come out clean. So "the compositor also retains stale layers in screenshot mode" is not supported.
2. The flag degrades output. On a transparent composition, comparing a software render against a hardware-GPU render of the same file, main differs from hardware only by antialiasing noise (max channel delta 12, zero opaque pixels wrong). With --disable-gpu-compositing added, the max delta goes to 255 and ~2700 fully opaque pixels come out with the wrong colour. It changes how SwiftShader rasterizes thin strokes and glyph edges. On an alpha render that is a regression, not a fix.

Where we think the bug is not

Your own evidence argues against the compositor, and we agree with it:

• Compositor flags had no effect on your dirty-frame rate.
• Static, non-animated elements are duplicated, so it is not timeline or layer-transform state.
• It survives Chrome 131 through Chrome 152. A live compositor bug across two majors that far apart is unlikely.
• Merging the SVG line primitives into one path removes it. That is a content-shape dependency, which points at paint or rasterization of those specific primitives, not at buffer reuse between captures.

Answering your three questions directly:

1. No. In screenshot mode the capture path is a plain Page.captureScreenshot with captureBeyondViewport: false and an explicit full-frame clip. There is no per-band or per-tile buffer we reuse between seeks.
2. Not one we can point at. The one known phantom-duplicate mode we have on SwiftShader is captureBeyondViewport: true, which we only request when a composition contains a native <video> surface, and which we downgrade back to false once we measure that content does not overflow the capture height. Your composition has no video and no external assets, so that path is not active for you.
3. Not yet, because we cannot reproduce it. We built a composition matching your description (240 static SVG line elements, transparent background, one paused GSAP timeline with a yoyo reversal, --format png-sequence --no-browser-gpu) and the alpha channel is clean on every frame. Consistent with your note that sibling compositions with more primitives render fine, the trigger looks specific to your content.

The ask

Please send the composition. You offered it in the report and it is now the blocker. A private channel is fine if it cannot be public. Once it reproduces on our side we can bisect it properly, and if it does turn out to be Chromium we will file upstream with a real minimal case attached. Filing now, with no repro and evidence pointing away from the compositor, would not help.

Two things that would narrow it fast in the meantime:

• Does it reproduce with --format png-sequence instead of --format mov? That separates capture from the alpha encode.
• Does it reproduce with --workers 1? That rules the parallel capture path in or out.

On the escape hatch

Noted and agreed. PRODUCER_EXTRA_CHROME_ARGS should exist so you can A/B Chrome flags without wrapping the binary. We will land it on its own, separate from any capture-path change.