Trim Paths timing is out of sync

[jhughes696]

Hi there, I am having issues with Trim Paths and an Alpha Inverted Matte being out of sync. On Android/ Web it plays as expected: the Trim Paths and the Matte play in sync with the animation of the "diamond" shape, so it always trails behind the "diamond" shape. But on iOS, the Trim Paths renders out of sync with a different timing, or could be interpreting different "Start/End" values perhaps? The Trim Path jumps out in front of the "diamond" shape, and breaks the illusion of a motion trail always staying behind the "diamond" shape.

Secondly, the Alpha Inverted Matte is out of sync, creating a stuttering effect. The Alpha Inverted Matte is parented to another layer, but it's not moving in sync with its parent. So it's creating a stuttering, time delay that's visually apparent due to the Matte layer's position being out of sync with it's parent.

Lastly, when the AlphaInverted Matte is in use, it crashes my LottieFiles previewer app on iOS. For some reason, the Alpha Matte seems to be too much to process?

Here is the AEP: https://www.dropbox.com/s/gwbvdo281s3dfno/TrimPathsBug_public.aep?dl=0

Which Version of Lottie are you using?

Lottie 3.3.0
iOS 15.6
iPhone 12 mini

Expected Behavior

Actual Behavior

Animation JSON

https://lottiefiles.com/share/thkvqxz3

[calda]

Secondly, the Alpha Inverted Matte is out of sync, creating a stuttering effect. The Alpha Inverted Matte is parented to another layer, but it's not moving in sync with its parent. So it's creating a stuttering, time delay that's visually apparent due to the Matte layer's position being out of sync with it's parent.

Lastly, when the AlphaInverted Matte is in use, it crashes my LottieFiles previewer app on iOS. For some reason, the Alpha Matte seems to be too much to process?

These issues are fixed by the Core Animation rendering engine, which has much better performance and now supports inverted mattes (as of #1712).

Unfortunately the issue with the stroke timing not matching the matte position also happens in the Core Animation rendering engine. I see issues from a few years ago mentioning similar issues, so there must be a bug somewhere in the foundation of where Lottie handles keyframe timings. If anyone is interested in digging in to this issue, it would be much appreciated!

Also unfortunately, there's a bug in the Core Animation rendering engine that causes the stroke to only render for half of the animation. This also happens with RenderingEngineOption.automatic, so I'll get this issue fixed asap. Thanks for the report!

[jhughes696]

Oh nice! So for the matte, I just need to make sure my client's eng team is using Lottie 3.4.0, is that correct?

Thanks for looking into/drawing attention to the Trim Paths bug. That would be a huge help to find a fix 🙌🏼

[calda]

Oh nice! So for the matte, I just need to make sure my client's eng team is using Lottie 3.4.0, is that correct?

Support for inverted mattes specifically was added within the past week or so and isn't included in the 3.4.0 or 3.4.1 release. It will be included in a following 3.4.2 release.

[jhughes696]

Ah I see, thanks for the info!

[jhughes696]

Is there an ETA on the v 3.4.2 release? Just curious

[calda]

I can release it soon, going to see if I can fix the stroke rendering bug first

[calda]

I fixed that issue that was specific to the Core Animation rendering engine in #1721. Will release 3.4.2 later today 👍🏻

[calda]

3.4.2 is now available

[jhughes696]

Amazing thanks! So re: "stroke timing not matching the matte position," that fix will have to come at a later date? Any sense of timing for that update? It would be helpful to know what to tell our client's engineers.

Also, in further testing this project file, I've found that the trim paths layer itself is causing extreme latency and sometimes crashes the app on iOS. And it does this irregardless of the presence or absence of an Alpha Matte. So I thought the Alpha Matte was causing the latency, but in fact it seems to be the Trim Paths layer. Because when I turn the Trim Paths layer off, then the scene plays smoothly. Is there any reason why a Gradient Stroke + Trim Path shape layer is causing so much latency? I know it's a very "large" layer bounds size, due to the nature of the tall motion path. Or maybe it has something to do with animating the Position of the gradient handles?

[calda]

I've found that the trim paths layer itself is causing extreme latency and sometimes crashes the app on iOS.

Using what rendering engine? There are known performance issues with gradients on the Main Thread rendering engine which should be fixed by the Core Animation rendering engine.

re: "stroke timing not matching the matte position," that fix will have to come at a later date? Any sense of timing for that update?

This issue affects both the Main Thread rendering engine and Core Animation rendering engine, so it must be a foundational in some of the older keyframe code that I'm less familiar with. Right now I'm specifically focused on achieving parity between the two rendering engine and not prioritizing bugs that affect both implementations.

[jhughes696]

Using what rendering engine? There are known performance issues with gradients on the Main Thread rendering engine which should be fixed by the Core Animation rendering engine.

I was previewing the animation using LottieFiles' iOS app which says it runs "Lottie 3.3.0." So is that considered the Main Thread rendering engine or no? Do you know of an easy way for us animators to test on the Core Animation rendering engine? I'm not an engineer/developer, and unfortunately we don't have any on our team, so what is currently the best way to test on the latest rendering engine? Would we have to create our own preview tool? I wish there was a way to always be able to test the latest rendering engine.

This issue affects both the Main Thread rendering engine and Core Animation rendering engine, so it must be a foundational in some of the older keyframe code that I'm less familiar with. Right now I'm specifically focused on achieving parity between the two rendering engine and not prioritizing bugs that affect both implementations.

Okay that's good to know. I'll try to work around this for now. If/ when that bug is fixed, will you announce that on this thread? Or is there another way I can stay in the know? Thanks Cal!

[calda]

I was previewing the animation using LottieFiles' iOS app which says it runs "Lottie 3.3.0." So is that considered the Main Thread rendering engine or no?

The Core Animation rendering engine was added in Lottie 3.4.0, so if the LottieFiles app uses Lottie 3.3.0 then it's definitely using the Main Thread rendering engine.

Do you know of an easy way for us animators to test on the Core Animation rendering engine?

The LottieFiles app is a great resource. Ideally they'll add a toggle switch for choosing the rendering engine to preview with. Until then I'm not sure there's a convenient no-code tool for testing the new engine.

If/ when that bug is fixed, will you announce that on this thread?

Yes, we would tag this issue in the PR that fixes the bug, and then mark this issue as resolved.

[jhughes696]

Got it, thanks!