Completion Closure Not Called in CA Mode Like in Main Thread Mode

[VaslD]

Which Version of Lottie are you using?

Lottie 4.4.0 (CocoaPods)

Expected Behavior

I'm expecting completion closure to be called in CA mode like in Main Thread mode.

Actual Behavior

When I play(…) two animations on the same AnimationView (now LottieAnimationView) consecutively, completion is called for both plays in Main Thread mode, but the behavior changes in the new CA mode.

I think the first completion closure is discarded incorrectly here by removeCurrentAnimationIfNecessary(), which simply sets the current AnimationContext holding the closure to nil:

where the previous animation has not come to a full stop, triggering CAAnimationDelegate to ultimately call the completion closure in the previous AnimationContext.

In Main Thread mode, removeCurrentAnimationIfNecessary() first calls removeAnimation(forKey:), which according to documentation does trigger CAAnimationDelegate callbacks.

[VaslD]

I would submit a PR but I fear I haven't read enough code to understand fully how CA mode works compared to Main Thread. I can't decide if animation should be removed first or the completion closure on the context should be called directly before setting the context to nil.

[calda]

Are you attempting to play multiple animations consecutively in a single run loop cycle?

The Core Animation rendering engine always batches animation setup to the next runloop cycle. This makes it if multiple playback state are triggered sequentially in a single block of code, only one will actually be built and rendered.

This is a pretty big performance improvement. With the Core Animation rendering engine in particular, it's expensive to build a new animation from scratch (which has to happen any time the playback state changes). One really common examples is that when initializing a LottieAnimationView, it initially defaults to displaying .paused(frame: 0) until you call play(). This optimization lets us avoid building and rendering the .paused(frame: 0) state in cases where you immediately call play() after initializing the animation view, which is a meaningful performance boost.

I'm guessing that, since the animation setup is batched, only the last animation you apply is actually getting played, and the rest are basically getting cancelled before being played.

[calda]

So, we shouldn't call removeCurrentAnimation() here.

I could imagine updating removeCurrentAnimationIfNecessary() to call the closure manually, but one issue I'd worry about is accidentally calling the completion closure too many times in other cases where we actually do begin playback of the animation.

[calda]

Could you share more details about the code you're writing and why this specific behavior matters for your use case?

[VaslD]

I'm guessing that, since the animation setup is batched, only the last animation you apply is actually getting played, and the rest are basically getting cancelled before being played.

Yes, this is expected behavior. I never expected multiple animations to play at once. (I don't think it's even possible even with Main Thread.) The thing that bothers me is losing the completion callback.

I have to maintain legacy code that expects every play() end with corresponding completion. In my defense, that's exactly what completion closures are for; and by convention, a completion closure/handler should always be called even due to cancellation/interruption.

Could you share more details about the code you're writing and why this specific behavior matters for your use case?

Sorry, I don't have a well structured demo with me at the moment. I just found this root cause to weird problems in our release build. I'll try to extract some business logic when I'm back at the office and see if I can create a demo.

[VaslD]

In case I couldn't come up with a valid scenario, (some old code just works, you know 😜; sometimes there's really no good reason it should, but it does; I'm really afraid I might run into one of those cases) think of this as a request for backward compatibility.

[VaslD]

Sorry for the delay. I did manage to extract the core code that caused missing completion, and it was a little different than what I described above. The completion block (AnimationContext) was reset during a call to LottieAnimationView.currentFrame setter (which also called down to removeCurrentAnimationIfNecessary()), not in another call to play.

To reproduce, write a button selector that does the following, or use the attached iOS project:

print("Started")
self.animationView.play(fromFrame: 15, toFrame: 65, loopMode: .loop) {
    print("Done:", $0)
}
self.animationView.currentFrame = self.animationView.frameTime(forMarker: "loading_failed") ?? 0

(I know this code does no real animation. It's just a minimal example to illustrate this issue.)

Lottie Playground.zip