[rumi7911]

A frame redraw now preserves initialized from-only values in authored tween order when its backward step crosses a fromTo start. After #5506, a same-time set before the tween can still overwrite its from-only value, and a reentrant from-state setter can leave interpolation at its initial value.

For example, set(pivot=42) followed by a fromTo starting at 0.1 with pivot=0 leaves pivot=42 on current main; this patch keeps pivot=0. When a setter reenters refresh at 0.1005, current main leaves x=10 rather than the expected interpolated x=10.045; the patch preserves 10.045.

The update is based on upstream e8eb358fe21d6f1a611e04f8df27ca366b337ce9 and retains #5506's implementation and two timing/overlap-playback tests. It replays already initialized from-state during the affected tween's actual render, suppressing standalone priming only for those replayed tweens. Temporary render descriptors and landing marks restore in finally. No public API, dependencies or render defaults change. The existing opening-boundary behaviour at t<0.001 is unchanged; this is not a claim to fix every same-time ordering case.

Validation on 13 October:

• Original 17 regression cases retained. Transferred tests fail 2/309 against untouched upstream and pass 309/309 with this patch.
• Independent review found no critical/important issues and reran 318/318 affected tests, including the general adapter suite.
• Full documented Bun build, workspace and script typechecks, root lint, changed-file formatting, comment checks/ratchet and pre-commit checks pass.
• Runtime CI contract gate passes, including 2,049 runtime tests and its coverage gate.
• Full core: 4,635/4,636 pass. Untouched upstream source: 4,618/4,619 pass. Both fail the identical 5,000 ms timeout in deterministicFonts-googleSubsets.test.ts, “still embeds a local file when the page has no Google link”. No font source changed.

The updated commit is GitHub-signed and Verified. These are local automated code/runtime checks; fresh CLI-export or human visual validation of this reconciled revision and completed upstream CI are not claimed. Maintainer approval and permission for fork workflows remain required.

Refs #5122, #5125, #5506.

[jrusso1020]

This needs a rebase before it can be reviewed for merge. The redraw code it changes has been substantially rewritten on main. Reviewed at 1e3ba0b0.

The bug is still there. I appended your new gsap frame refresh from-state block to main's gsap.steps.test.ts and ran it against main's gsap.ts. Two cases still fail: "keeps interpolation when a from-state setter reenters the refresh" (expected 10 to be close to 10.045) and "keeps from-only writers in authored order (set last: false)" (expected 42 to be +0). So the fix is still needed.

But gsap.ts and gsap.steps.test.ts both conflict. Since your base (e8eb358f), three PRs reworked rerenderGsapTimelineAt: #5614 (seeks go through seekGsapTimeline), #5674 (landing marks are placed and cached per structure) and #5766 (reapplyStepsInAuthoredOrder replays a scene's same-time steps in authored order when scrubbing back onto them). The conflict is not mechanical, because the try block you edit is now renderOntoInAuthoredOrder.

When you rebase, please look at building on that new machinery instead of adding a second one. Main now has stepsAt / reapplyStepsInAuthoredOrder for the "same-time steps must land in authored order" problem, and today it only runs on the !below path. Your case is the below path crossing a fromTo start, which looks like the same problem on the other side. Extending that one mechanism would likely be smaller than temporarily replacing each crossed tween's own render method and reading _tTime. Wrapping render works, but it's a second way of forcing authored order that the next person has to keep in sync with the first. If it really can't be expressed through the landing-mark path, a sentence in the description on why would help.

Need: yes, 2 of the new cases fail on current main. Size: ok. Reuse: should build on main's reapplyStepsInAuthoredOrder / stepsAt from #5766. Simpler: likely yes, via that path.

— Rames