Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#4,435 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@user-github-me ya está trabajando en esto.

Desde el 8/10/2026.

  • #5204 de @user-github-me — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
html, typescript
Área
computer-graphics

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
54.1k
Forks
4.9k
Merge medio
7 h 19 min
PR fusionados (30 d)
746

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de heygen-com/hyperframes

Todos los issues de heygen-com/hyperframes

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.