-
-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix CoreAnimation playbackState
race condition
#1727
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems reasonable to me, especially for behavior compatibility with the main thread rendering engine that doesn't have this two-phase animation setup flow.
@@ -331,7 +331,7 @@ extension CoreAnimationLayer: RootAnimationLayer { | |||
var isAnimationPlaying: Bool? { | |||
switch playbackState { | |||
case .playing: | |||
return animation(forKey: #keyPath(animationProgress)) != nil | |||
return pendingAnimationConfiguration?.playbackState == .playing || animation(forKey: #keyPath(animationProgress)) != nil |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does this pendingAnimationConfiguration?.playbackState == .playing
check need to be nested in the playbackState == .playing
branch? Could we move it out of the switch and have it be checked first?
What happens if pendingAnimationConfiguration?.playbackState == .playing
when playbackState == .paused
or nil
? Is there a reason we only have to do this check when another animation is already playing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good point, I guess I was too focused on that this is the line that changed and therefore I wanted to put it there. I'll push a different proposal and you can react to that :-D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updates lgtm, thanks!
…mation set by `AnimationView` (#1727)
…mation set by `AnimationView` (#1727)
…mation set by `AnimationView` (airbnb#1727)
#1682 introduced a bug where infinitely looping animations would sometimes report as not playing. I think this is because the property is read while a new animation is scheduled but haven't yet been applied through the
display
lifecycle method. This PR changes theplaybackState
to take the pending animation configuration into consideration which fixes the bug on our end, but happy to see if you have a better approach at fixing this.