fix(three): drive demand-mode frameloop so looping animations don't freeze#2536
Merged
Conversation
…reeze Under `frameloop="demand"` a looping/sequenced animation froze after ~1 segment: rafz is driven from r3f's render loop, which sleeps unless frames are requested, and the loop-restart scheduled in the microtask gap was never rendered. rafz now signals pending frame work via `onDemand`; the three target turns it into a deferred `invalidate()` that restarts r3f's loop. Demand mode is preserved (the canvas sleeps once settled). Closes #2402.
🦋 Changeset detectedLatest commit: 0a44704 The changes in this PR will be included in the next version bump. This PR includes changesets to release 12 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Looping, sequenced, and delayed animations froze under
@react-three/fiber'sframeloop="demand". The goal: they should run to completion (and keep looping) with noinvalidate()-in-events oruseFrameworkarounds, while the canvas still sleeps when nothing's animating.Why it happened
The three target drives
rafzfrom r3f's render loop, which only runs while frames are requested viainvalidate(). At a segment boundary the spring goes idle for the microtask gap while the next segment is scheduled — r3f's loop stops and nothing restarts it. Event-driveninvalidate()can't bridge it: from r3f's "before" phase it's cancelled by the same-frame frame-count decrement.The fix
rafzexposes anonDemandsignal that fires while it has pending frame work; the three target turns it into aninvalidate()deferred a microtask, which restarts r3f's loop after it stops. Demand mode is preserved — once the animation settles,rafzgoes idle and the canvas sleeps. A regression guard in@react-spring/coremodels a bare r3f demand host and asserts aloop: trueanimation keeps cycling.Closes #2402.