Skip to content

fix(core): same-time sets at 0 land in authored order on the first frame - #6851

Merged
miguel-heygen merged 1 commit into
mainfrom
fix/gsap-same-time-sets-at-zero
Oct 30, 2026
Merged

miguel-heygen merged 1 commit into
mainfrom
fix/gsap-same-time-sets-at-zero

Conversation

@miguel-heygen

Copy link
Copy Markdown
Collaborator

fails without the fix: shows the first step's frame when seeking to 0 from %s s (three cases) in packages/core/src/runtime/adapters/gsap.steps.test.ts

What

A film built from repeated same-time sets (tl.set(all, hidden, t) then tl.set(one, visible, t) at every step) showed nothing on its first frame: at time 0 both sets are applied, but in reverse order, so the "hide all" set lands last. Every later step was right. The timeline re-render near 0 renders just above 0 and then steps back to 0, and the step back replays the sets at 0 in reverse; the code that puts them back in authored order only ran when a structure key was passed, which a render capture deliberately does not pass. It now derives the owner from the timeline's own children and always reapplies the steps at the landing time.

What I measured

  • End to end on a Linux box, 12 sprites, each step set(all, opacity 0) then set(one, opacity 1) every 0.1 s, frame at 0 shows s0 when correct:

    before (hyperframes 0.8.221) after (CLI built from head caf9b4ce)
    snapshot --at 0 no sprite s0
    render frame at 0 s no sprite s0
    render frame at 0.4 s s4 s4

    Steps after 0 (0.1 to 1.0 s) were already correct before.

  • The three new cases are red with gsap.ts at main, green with the change. packages/core runtime suite: 109 files, 2658 tests pass. oxfmt --check and oxlint clean.

What I did NOT execute

  • The reporter's own project; the repro is my reduction of their description, and their sprites hid at 0.4, where my reduction already rendered correctly. The first frame is the case I could reproduce.
  • Hooks skipped on commit (no node_modules in the worktree); the checks above ran on a Linux box.

Size

Lone fix nothing can carry: a few lines in the GSAP seek adapter and one parameterized test; it cannot be folded into another PR.

@github-actions

Copy link
Copy Markdown
Contributor

Edit accuracy: accurate 271 (base branch 271), smooth 112 of those

The gate passes.
Smoothness is reported in the artifact, not gated. A case fails only if it fails 2 of 3 runs.

Quarantined, measured but not gated (0)

@heygengenesis heygengenesis Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Verdict: APPROVE · 0 blocker · 0 important · 0 nits · head caf9b4ce

Scope

Read gsap.ts and how init.ts drives it with structure undefined during render capture. The owner comes from getChildren(false, …)[0].parent, which is the real timeline even behind the bound wrapper. version: "" takes the uncached placeLandingMarks, so the per-revision cache can't go stale, and that path only runs for t < REDRAW_STEP. Capture and the adapter now reapply steps at 0 the same way preview already did. Red/green confirmed locally: all three shows the first step's frame when seeking to 0 from %s s cases fail with main's gsap.ts and pass at head, and the file passes 77/77. Every required check is green. The one red job, the optional Catalog payloads, failed with "Could not download the pinned catalog embedding model" (network, unrelated); I re-ran it.

@miguel-heygen
miguel-heygen added this pull request to the merge queue Oct 30, 2026
Merged via the queue into main with commit aafbd96 Oct 30, 2026
146 of 147 checks passed
@miguel-heygen
miguel-heygen deleted the fix/gsap-same-time-sets-at-zero branch October 30, 2026 19:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant