Unexpected behaviour when changing text & speed on a playing animation

[wtfparadox]

Which Version of Lottie are you using?

Lottie 4.2.0

Expected Behavior

I would expect static text in an animation to be editable as the animation is playing, regardless of the rendering engine.
Also, I would expect that changing the animation speed while playing an animation happens smoothly when the rendering engine is set to automatic (it is smooth on mainThread).

Actual Behavior

In this example I have made some code that changes the speed of the animation every 0.5 seconds as its playing. It also change the text of the textprovider every 0.5 seconds. When the rendering engine is set to .automatic (top animation), the animation seems to have some jitter every time the speed is changed (it seems to be playing it from a slightly earlier frame). The text updates nicely here. When rendering engine is set to .mainThread (bottom animation), the animation updates smoothly. However, the text is never updated anymore. I have tried calling forceDisplayUpdate() but this has no effect on the text.

lottie-animaton.mov

[wtfparadox]

Sample project used to create the video above:
dynamic-lottie-poc.zip

[calda]

To have the main thread rendering engine update its text dynamically, it may be necessary to add a new reloadText() method similar to the existing reloadImages() method.

[ZB199374]

I also encountered the same problem, I could not update the text in the main thread, is it solved now？

[calda]

I don't fully understand the jitter you mention in the Core Animation rendering engine. When I run the sample app you shared, the behavior seems reasonable to me. There's a lot going on so I may be missing something. Perhaps a simpler example would help me understand better.

[calda]

When changing the playback speed, the Core Animation rendering engine currently rebuilds the entire animation. As far as I can tell when testing it's not possible to modify the playback speed of the CAKeyframeAnimations just by changing layer.speed -- it seems like you have to actually rebuild the keyframes.

Rebuilding the animation takes time, which is why you're seeing this choppiness. I was able to reproduce this in our sample app when changing the animation speed rapidly multiple times in succession.

the animation seems to have some jitter every time the speed is changed (it seems to be playing it from a slightly earlier frame)

What I think may be happening here:

1. the current frame is read from the in-flight animation
2. rebuilding the animation takes a moment, which momentarily blocks the main thread
3. meanwhile, the existing animation continues playing (since core animation doesnt't run on the main thread)
4. then, once the new animation is finished being set up, it starts playing from the frame read in step 1

If you instead do something like:

1. read the current realtime frame
2. pause the animation at that frame
3. start a new animation with the new speed, from the paused frame

then this jump would probably go away

[wtfparadox]

Thanks for looking into this!

I have tried your suggestion (two snippets with different implementations below) but I think it does not resolve the issue.

randomSpeedAnimationAutomatic.pause()

// Store pause frame
let frame = randomSpeedAnimationAutomatic.realtimeAnimationFrame
randomSpeedAnimationAutomatic.animationSpeed = speed

// Reload animation
randomSpeedAnimationAutomatic.animation = animation

// Move animation to paused frame
randomSpeedAnimationAutomatic.currentFrame = frame

// Resume animation
randomSpeedAnimationAutomatic.play()

randomSpeedAnimationMain.pause()

// Store paused frame
let frame2 = randomSpeedAnimationMain.realtimeAnimationFrame
randomSpeedAnimationMain.animationSpeed = speed

// Reload animation
randomSpeedAnimationMain.animation = animation

// Resume animation and restart if it finishes within the update interval
randomSpeedAnimationMain.play(fromFrame: frame2, toFrame: animation!.endFrame) { didFinish in
    if didFinish {
        self.randomSpeedAnimationMain.play()
    }
}

With the core engine this still results in choppiness, it still seems that the animation gets resumed from a frame slightly earlier than the provided pause frame in both cases. The bottom implementation has its own issues, but i included it for completeness. It also shows the choppiness. To see this will I used an update interval of 0.1 seconds (10 updates per second).

To me it suggests the following potential issues that may or may not be the cause of the observed behaviour:

• core engine pause frame is set while the animation is not yet paused (so it may play for a few more frames until the pause freezes the animation). This would cause a jump back in time when replaying from the given pause frame.
• core engine replays animation from an earlier frame than provided via the play method or currentFrame method.

Thats what I could come up with for now, I hope it gives you some extra insight in the situation.

[calda]

Did you try something like:

// Pause the animation at the current frame
randomSpeedAnimationAutomatic.pause()

// Update the speed while the animation is paused
randomSpeedAnimationAutomatic.animationSpeed = newSpeed

// Play the animation again, which will begin playing from the current paused frame
randomSpeedAnimationAutomatic.play(toProgress: 1)

[wtfparadox]

I gave it a shot after seeing your message. I dont think it resolves the issue though. Ive attached a video below with the result

lottie-jitter-close.mov