Using CoreAnimation Engine Layer also blocks main thread when animation is set

[aakarsh-sasi]

Using core animation engine has improved the performance far more, no animations get stuck while playing anymore and it feels really great to use it

We were trying to go a little overboard and try to use animation inside table view cells (all cells with lottie animations)
We noticed whenever we set:
lottieAnimationView.animation = animation
there is a spike on the main thread and leads to stutter in scrolling experience. I know using Lottie in every cell was never the purpose it was intended for 😅

We managed to decrease the time it takes on main thread by using the DefaultAnimationCache and dictionary Based Decoding (from 4.0.1)

Checked a bit in code and the time is mostly taken on makeCoreAnimationLayer

Is it possible to optimise it any further through any workaround? (We tried setting the animation on a background thread but that didn't work)

Adding the screenshot for the profiler:

Which Version of Lottie are you using?

Lottie 4.0.1

Expected Behavior

60 FPS if possible :p

Actual Behavior

Frames drop to 8-10 fps if I scroll really fast

Animation JSON

[calda]

I'd say this is generally expected, since it does take some amount of work on the main thread to set up and configure the Core Animation rendering engine's CALayers and CAAnimations. There's probably room for more optimization of course.

We have test cases comparing the initialization performance of the Core Animation rendering engine compared to the Main Thread rendering engine and they show that the CA engine is usually about 2x as expensive to initialize (optimized from 4-5x originally).

[calda]

Thinking about this more -- unlike UIViews which have to be set up on the main thread, we should have the ability to set up our CALayers and CAAnimations on a background thread. I'll see if I can find a chance to investigate if that works in practice.

[programmatrix88]

@aakarsh-sasi @calda
Did you observe any relation with lotties size and performance?
@calda
does that mean we should not have animations in UITAbleview cells? and if yes then in addition in using core animation engine for lotties what other factors to look for ?

[programmatrix88]

Also, .dotLotties are not working under uitableviewcell-->UIcollectionView cell ? Any idea ?

[mkj-is]

If the animation has a high number of layers (hundreds) it can take seconds to initialize. This frequently happens during a critical time during a screen load where other intensive work is happening at the same time.

In my experience, it is easy to get over this number. A typical case for us is the use of compositions (assets). If those composions are copied and nested the number of layers can grow exponentially.

I propose we experiment with the following ideas to mitigate this:

1. Add signpost logging to be able to profile loading times for animations. This will allow the creation of performance tests for animation loading times.
2. Build the CALayer hierarchy in the background, to not block the main thread during the animation initialization. DotLotties are unzipped and parsed in the background. We can move the last expensive step to a background thread too.

We are willing to help with the implementation but would like to agree on the approach first.

[calda]

I'd definitely be interested in supporting having the CALayer hierarchy and CAAnimations initialized in the background. We'd probably have to make this opt-in, though, since letting Lottie views be blank for a moment while waiting for the animation to be initialized is not a great default behavior.