Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

render: parallel worker's first frame still captures pre-seek state — #2477 fix never landed (0.8.72)

未关闭
#4,435 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
52/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
html, typescript

调研方向

Start in frameCapture.ts and trace the parallel worker path that calls captureFrame; inspect how discardWarmupCapture is intended to participate, along with its re-export in engine/src/index.ts. Reproduce with the provided multi-worker HTML composition and alpha scan. Done means non-zero worker shards capture their seeked state without transparent first frames, while single-worker behavior remains unchanged.

由索引模型根据 Issue 内容生成。

描述

Describe the bug

Re-opening the #2477 symptom on 0.8.72: parallel capture emits a fully transparent frame at each worker shard's first frame. The fix PR #2489 was closed unmerged, and discardWarmupCapture still has zero call sites on current main (a3d7736) — only its definition in frameCapture.ts and the re-export in engine/src/index.ts.

Observed with a transparent ProRes 4444 render of a canvas/DOM overlay composition (120 frames @ 24fps, --workers auto → 4 workers, screenshot capture mode): frames 30, 60, 90 decode fully transparent — exactly shardStart = w * (totalFrames / workers) for workers 1–3. Worker 0's first frame is naturally identical to t=0 so it's invisible in the alpha scan. --workers 1 produces zero blank frames; the anomaly is deterministic in position across parallel runs but intermittent (some runs clean), matching the paint-settle race described in #2477.

Notable difference from the original report's setup: our composition registers a non-GSAP duck-typed RuntimeTimelineLike on window.__timelines ({duration, time, seek, totalTime, pause, paused, play, add, set} — pure seek→redraw, no GSAP). If the post-#2477 warm-up logic engages only for GSAP timelines or on a code path duck timelines don't reach, that would explain why the regression survives for this comp shape.

Steps to reproduce

The race is timing-sensitive — a heavier page (custom fonts, canvas setup, larger script payload) widens the window. Composition shape that fails for us ~half the time at 4 workers:

<div id="root" data-composition-id="repro" data-duration="4"
     data-width="1920" data-height="1080">
  <div id="box"></div>
</div>
<script>
  var t = 0;
  window.__timelines = window.__timelines || {};
  window.__timelines["repro"] = {
    duration: function(){ return 4; },
    time: function(){ return t; },
    seek: function(s){                      // pure seek->redraw contract
      t = Math.max(0, Number(s) || 0);
      // visible whenever t>0; only t=0 state is blank
      document.getElementById("box").style.opacity = t > 0.02 ? "1" : "0";
    },
    totalTime: function(s){ this.seek(s); },
    pause: function(){}, paused: function(){ return true; },
    play: function(){}, add: function(){}, set: function(){}
  };
</script>

Detection (alpha scan, same method as #2477):

ffmpeg -i out.mov -vf "alphaextract,signalstats,metadata=mode=print" -f null -
# frames at w * ceil(totalFrames/workers) show alpha mean ~0 between normal neighbors
Expected behavior

Every worker's first captured frame contains the seeked state — e.g. wire discardWarmupCapture into the parallel worker path (it already exists and is exported), or gate the first captureFrame on a post-seek paint commit rather than the seek alone.

Actual behavior

First frame of each non-zero worker shard captures the pre-seek page state (t=0). For fade-in/transparent overlays that state is fully transparent, producing visible flicker in the baked output.

Environment
  • [email protected] (managed npm install)
  • macOS arm64, chrome-headless-shell 152.0.7977.30 (CLI-managed cache)
  • screenshot capture mode (drawelement not engaged for this comp)
  • Output: --format mov (ProRes 4444, yuva444p12le), --fps 24
Additional context

Workaround confirmed on our side: --workers 1 removes the anomaly entirely (verified across a 37-template regression suite with per-frame RGBA diffing). Filing mainly so the #2477 fix can land — the reporter there already wrote it.

主要语言
TypeScript
星标
54.1k
派生
4.9k
平均合并
7 小时 2 分钟
30 天内合并 PR
782

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南,环境需要你自己搭建:先看它的 README,通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

heygen-com/hyperframes 的其他 Issue

查看 heygen-com/hyperframes 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。