[adapter-hyperframes] Multiple render bugs with frame-light-leak-cinema template — visual effects missing, animation jumps to end-state, multi-scene duration broken

[walliai666]

Environment

• OS: macOS 26.5.1
• Node.js: v25.9.0
• pnpm: 9.15.0
• Template: frame-light-leak-cinema
• Content type: 概念解说短片
• Adapter: adapter-hyperframes

Problems

1. Visual effects missing in exported MP4

Effects like backdrop-filter, mix-blend-mode, and SVG filters visible in the browser
preview are completely absent in the exported video. The output looks nothing like the
in-browser preview.

2. GSAP animation jumps to end-state at frame 0

On templates using GSAP, the exported video opens with all elements already in their
final state (e.g. fully opaque, already in final position). The entire entrance
animation is skipped — the clip looks like it was recorded starting from the last frame.

3. Multi-scene duration broken (NaN / wrong timing)

When using a multi-composition template, each scene's duration is wrong. Animations
play too fast or get cut off mid-way. Root cause: the __VIDEO_DURATION__ placeholder
inside composition files is never substituted with the actual value, so timelines
receive NaN and timing collapses.

4. Silent failure — blank/black video with no error message

When a page-level JS error occurs during render, the output is a blank or near-black
video with no indication of what went wrong. There is no error surfaced to the user.

Root Causes (investigated)

1. Missing --disable-gpu / --use-gl=swiftshader flags — Chromium silently drops
   composited effects on headless machines without a GPU.
2. GSAP pause injected too early — addInitScript runs before GSAP's wake()
   reassigns window.gsap, discarding the patch. Initial element states set by
   gsap.set() in DOMContentLoaded are also skipped, causing the jump-to-end-state bug.
3. prepareSourceHtml hardcoded '15' and did not substitute __VIDEO_DURATION__
   inside child composition files.
4. No page.on('pageerror') listener and no webm size guard to catch silent crashes.

Fix

I have a fix ready for all four issues in packages/adapter-hyperframes/src/render.ts:

• Add --disable-gpu + --use-gl=swiftshader to Chromium launch args
• Move GSAP pause to after DOMContentLoaded + 100ms tick; atomically seek(0) +
  resume() at recording start
• Pass totalDuration into prepareSourceHtml and substitute placeholders in both
  the entry HTML and all child composition files
• Add page.on('pageerror') / page.on('console') listeners and a webm size guard
  (< 10 KB → throw with actionable message)

Happy to open a PR with this fix. Let me know if you'd like me to proceed.

[lefarcen]

Hi @walliai666 — really appreciate how far you pushed the investigation here. The prepareSourceHtml() hardcoded __VIDEO_DURATION__ replacement and the lack of page-level error surfacing are both visible in the current packages/adapter-hyperframes/src/render.ts, and PR #60 is already open on the GSAP end-state path in the same renderer.

Please go ahead and open a PR for the broader fix set. The most helpful shape would be to reference both this issue and #60 in the PR description, and spell out which parts overlap vs. which parts are new — especially the GPU/composited-effects path, child-composition duration substitution, and the blank-video error surfacing.

Keeping it scoped to packages/adapter-hyperframes/src/render.ts with a short repro note for each of the four cases should make review pretty straightforward. Looking forward to it.

[walliai666]

@lefarcen Thanks for the detailed feedback!

Before I start working on the broader fix set, I'd like to wait for PR #60 to be merged since it touches the same renderer and may affect some of the behavior I'm investigating. I'd prefer to verify which issues still reproduce on top of the latest code before preparing a follow-up PR.

If possible, could you take a look at PR #60 when you have a chance? That would help me validate the remaining issues and avoid overlapping changes.

Once #60 is merged, I'll retest the four cases and open a PR for the remaining fixes, clearly calling out what overlaps with #60 and what is newly addressed.

[lefarcen]

Hey @walliai666 — that sequencing makes sense.

Waiting for PR #60 to settle first is the right call if it changes the same renderer path. Let's keep this issue open for the broader follow-up: once #60 lands, please retest the four cases on top of the latest code and drop a quick update here with what still reproduces. If the remaining fixes are still all in packages/adapter-hyperframes/src/render.ts, a focused follow-up PR from there should be a clean next step.

[lefarcen]

Hey @walliai666 — one quick follow-up from my side: PR #60 is still open right now, so your plan to wait and retest on top of that branch after it lands still looks like the right path.

No extra action needed from you before that. Once #60 is merged, please re-run the four cases and post what still reproduces — that will make it much easier to keep the next PR tightly scoped to the remaining renderer gaps.