CoreAnimation render engine displays an incorrect path animation.

[wzxha]

lottie json: 8f306fb14498d4e6a81bf5eff1d29ffe.json
lottie version: master branch at commit(adec48e)

I have a simple Lottie JSON file that contains a pure vector shape animation.

When rendered on the MainThread engine, it works fine. However, when using the CoreAnimation engine, there's an issue

CoreAnimation	MainThread

As you can see, the middle small white (alpha) triangle is missing in the CoreAnimation engine.

Please take a look at this issue when you have a moment, thx!

[dinozaurus0]

Hey everyone 👋

I reproduced the issue and ran a quick debug to print the layer tree for CoreAnimation engine. It looks like this:

🚀 CALayer frame: (0.0, 0.0, 440.0, 860.0)
  🚀 LottieAnimationLayer frame: (0.0, 0.0, 78.0, 78.0)
    🚀 CoreAnimationLayer frame: (-2.842170943040401e-14 ≈ 0, 210.0, 440.0, 440.0)
      🚀 ShapeLayer (name: "hj") frame: (0.0, 0.0, 78.0, 78.0)
        🚀 BaseAnimationLayer (name: "hj (Content)") frame: (0.0, 0.0, 78.0, 78.0)
          🚀 GroupLayer frame: (0.0, 0.0, 78.0, 78.0)
            🚀 GroupLayer frame: (0.0, 0.0, 78.0, 78.0)
            🚀 ShapeItemLayer frame: (0.0, 0.0, 78.0, 78.0)
              🚀 CAShapeLayer frame: (0.0, 0.0, 78.0, 78.0)

I inspected the CAShapeLayer animations. The latest CAShapeLayer has two animations: one for the path and one for the fill color. I copied those two animations onto a fresh CAShapeLayer and it reproduces what the CoreAnimation engine displays — so those animations themselves look correct.

Here’s the odd part: there is no animation for the second path (the one from Lottie that contains the inner shape). I copied that second path into a separate CAShapeLayer to verify the geometry (triangle + rectangle) and the shapes are fine. But none of the layers in the tree above contain any animation for that inner shape.

My current uneducated guess is that the inner shape is being dropped somewhere in the conversion fromLottie layer to CoreAnimation layers. I need to step through the layer-building pipeline more carefully to see where it’s lost.

[dinozaurus0]

Hey everyone 👋

I have updates on this issue. Was able to make it work correctly using CoreAnimation render engine (with some changes) but I haven't yet solve the bug. In short, my assuption turned out to be correct. The CoreAnimation engine skips the inner shape animation all together.

Let's first inspect the structure that is decoded from the lottie file. We will get to have a Group that has 4 items. Those look like this:

▿ 4 elements
  ▿ 0 : <Shape: 0x60000172ef80>
  ▿ 1 : <Group: 0x600000c20480>
  ▿ 2 : <Fill: 0x600001714c00>
  ▿ 3 : <ShapeTransform: 0x60000290d180>

I haven't followed all the possible code paths for them but I remove one by one to see what happens to the animation. What I wanna say with this is that I might not be 100% correct. Anyway my findings are as follow:

Shape -> Is the outer shape that we see on the screen. From Lottie file this is Shape 1.
Group -> Is the inner shape that is not displayed. From Lottie file this is Shape 2.
Fill -> Gives the color to the outer shape.
Shape Transform -> Moves the outer shape into correct position (I did not test this but I would asume this applies to the inner shape as well by moving the parent CALayer. This is not directly placed on the CAShapeLayer).

As per my last message we had the following layer structure:

🚀 CALayer frame: (0.0, 0.0, 440.0, 860.0)
  🚀 LottieAnimationLayer frame: (0.0, 0.0, 78.0, 78.0)
    🚀 CoreAnimationLayer frame: (-2.842170943040401e-14 ≈ 0, 210.0, 440.0, 440.0)
      🚀 ShapeLayer (name: "hj") frame: (0.0, 0.0, 78.0, 78.0)
        🚀 BaseAnimationLayer (name: "hj (Content)") frame: (0.0, 0.0, 78.0, 78.0)
          🚀 GroupLayer frame: (0.0, 0.0, 78.0, 78.0)
            🚀 GroupLayer frame: (0.0, 0.0, 78.0, 78.0)
            🚀 ShapeItemLayer frame: (0.0, 0.0, 78.0, 78.0)
              🚀 CAShapeLayer frame: (0.0, 0.0, 78.0, 78.0)

As we can see there are 2 GroupLayer. One has no children while the other has the ShapeItemLayer which is drawing the outer path on the screen. Now the reason the second shape is dropped is because the following method:

extension [ShapeItemLayer.Item] {
  func shapeRenderGroups(groupHasChildGroupsToInheritUnusedItems: Bool) {}
}

The part of the method that drops this is the renderGroups iteration with flatMap. It doesn't return any valid
groups when it looks at the lottie Group that contains the second path.

I commented that part out and this partially solved the issue. I say partially because to make it work I did some changes directly into the layer tree. I found the GroupLayer that is the parent of the inner path and had to change the following:

• The ShapeItemLayer that contains the outer path has to have a negative ZPosition so that it doesn't cover the inner path.
• Inner path doesn't seem to come with an animation for fill. By default it has a clear color. In the below example I gave it one by hand but this should not be done like so :(

For reference here is the layer structure that yields a correct visual representation:

🚀 CALayer frame: (0.0, 0.0, 440.0, 860.0)
    🚀 LottieAnimationLayer frame: (0.0, 0.0, 78.0, 78.0)
        🚀 CoreAnimationLayer frame: (-2.842170943040401e-14, 209.99999999999997, 440.0, 440.0)
            🚀 ShapeLayer (name: "hj") frame: (0.0, 0.0, 78.0, 78.0)
                🚀 BaseAnimationLayer (name: "hj (Content)") frame: (0.0, 0.0, 78.0, 78.0)
                    🚀 GroupLayer frame: (0.0, 0.0, 78.0, 78.0)
                        🚀 GroupLayer frame: (0.0, 0.0, 78.0, 78.0)
                            🚀 ShapeItemLayer frame: (0.0, 0.0, 78.0, 78.0)
                                🚀 CAShapeLayer frame: (0.0, 0.0, 78.0, 78.0)
                        🚀 ShapeItemLayer frame: (0.0, 0.0, 78.0, 78.0)
                            🚀 CAShapeLayer frame: (0.0, 0.0, 78.0, 78.0)

First CAShapeLayer draw the inner shape and the second draws the outer.

Next investigating why the second path is considered invalid & why it doesn't receive a fill animation by default.
@calda If you have any suggestions for me, I’d be more than happy to hear them 🙏

Video done with CoreAnimation renderer and the changes mentioned above:
https://github.com/user-attachments/assets/0ac37d6c-2236-4121-be12-c43c736acda6

[calda]

Nice!

I wonder what existing animations in the test suite this change affects. That would be good to know.

[dinozaurus0]

Hey everyone 👋

Had the chance to play more with this issue and managed to find a solution. However the solution doesn't respresent a code change but rather a structure change for the lottie file. I am not sure this is an optimal solution :( I will try to explain why I went this way.

According to the last message there was 3 issues:

• inner shape was not decoded from the lottie file
• inner shape had no fill color
• Z position for inner shape was not correctly set

The first 2 issues can be solved with the same approach. Now the lottie file has only one fill color that applies to the outer shape. If my understanding is correct this also apply to the inner shape, due to being part of the same group. However, even if it does we would not be able to distinguish between the 2 shapes, as they have the same fill color. From my perspective it doesn't make much sense for both shapes to have same fill color. (I don't know how the Lottie file was generated or why the MainThread renderer works just fine. For the latter my assuption is that no color means it gives a white color with no transparency. Hence this works for that renderer).

Now the reason I mentioned this also solves the decoding issue is because the reason the group was not decoded is due to this line from the method shapeRenderGroups:

 let (strokesAndFills, otherItems) = group.otherItems.grouped(by: { $0.item.isFill || $0.item.isStroke })

Long story short, if a shape has no stroke or fill inside a group it isn't considered valid. Given what I mention above, that it doesn't make sense to have a shape without a fill/stroke color, I belive this implementation is correct. Because of this I don't think the code should be updated to handle that case. I mean we can do that and give a default color but I think this can:

• create confusion
• interact in a bad way with existing code where people expect to give shapes a valid fill color (we might end in situations where the lottie file contains a certain fill color but we override it with a default one).

As a first conclusion the solution for the fill & decoding issue was to just give a fill property to the group that holds the inner shape.

Now let's recall the structure that we had when decoding the json:

Group:
1. Outer Shape
2. Group:
 2.1. Inter Shape
 2.2. Transform
3. Fill Outer Shape
4. Transform

After modifying this we have:

Group:
1. Outer Shape
2. Group:
 2.1. Inter Shape
 2.2. Transform
 2.3. Fill
3. Fill
4. Transform

The Z position was a bit harder to solve. Again I went through the code and from my perspective it doesn't make sense to modify the existing implementation. The reason the issue happen in the first place is because the outer shape gets to be added later into the layer tree so the inner shape, even if it is decoded and ready to work, it is covered by the outer shape.

First let's look in the existing code what generated the problem. In GroupLayer we have the method setupLayerHierarchy, which sets the layer tree. Whenever this finds an inner group in an existing group it tries to decode it and it will add the layer into the layer tree. Let's consider our example to better explain this. The following happens:

1. we get to this method with 4 items: outer shape, group (contains inner shape), fill & transform.
2. method finds the group and goes on that branch to decode the group. It decodes: inner shape, transform & fill.
3. adds this to a layer and adds the layer inside the layer tree.
4. goes back to step 1 and continues the creation of the layer.
5. adds the layer with the outer shape in the layer tree.

The problem here is obvious. The layer order is incorrect. The way in which the layer tree is created makes the outer layer cover the inner layer as it is placed later in the layer tree, hence has the greater Z index.

I could try to modify the logic in which the above method stops and go inside child groups, but I am not sure how this would affect existing functionality. Besides I am pretty sure there is a strong reason why it is implemented like this.

An obvious solution here is to invert the order of the groups, so that the inner one gets to be displayed in front of the outer one. After a lot of trial and error the above structure of the decoded element looks like this:

Group:
1. Group 
 1.1 Outer Shape
 1.2. Fill
 1.3. Transform
2. Group:
  2.1. Group:
   2.1.1: Inner Shape
   2.1.2: Transform
   2.1.3: Fill
  2.2. Transform

It might look a bit more complicated but it was the only way I was able to keep the same behaviour. After this changes the layer tree looks like this:

🚀 CALayer frame: (0.0, 0.0, 440.0, 860.0)
    🚀 LottieAnimationLayer frame: (0.0, 0.0, 78.0, 78.0)
        🚀 CoreAnimationLayer frame: (-2.842170943040401e-14, 209.99999999999997, 440.0, 440.0)
            🚀 ShapeLayer (name: "hj") frame: (0.0, 0.0, 78.0, 78.0)
                🚀 BaseAnimationLayer (name: "hj (Content)") frame: (0.0, 0.0, 78.0, 78.0)
                    🚀 GroupLayer frame: (0.0, 0.0, 78.0, 78.0)
                        🚀 GroupLayer frame: (0.0, 0.0, 78.0, 78.0)
                            🚀 ShapeItemLayer frame: (0.0, 0.0, 78.0, 78.0)
                                🚀 CAShapeLayer frame: (0.0, 0.0, 78.0, 78.0)
                        🚀 GroupLayer frame: (0.0, 0.0, 78.0, 78.0)
                            🚀 GroupLayer frame: (0.0, 0.0, 78.0, 78.0)
                                🚀 ShapeItemLayer frame: (0.0, 0.0, 78.0, 78.0)
                                    🚀 CAShapeLayer frame: (0.0, 0.0, 78.0, 78.0)

I know this is not the traditional fix, but I think changing the existing implementation for this corner case implies changes that, from my perspective, either don't make a lot of sense (fill) or might affect in a bad way the existing implementation (Z index).

I will attach the new lottie file that works for CoreAnimation renderer. As a side note, the new file still works for the MainThread renderer so no harm done.

I wanted to ask you @calda if this is a proper resolution for the ticket or should I experiment more with changing existing code to cover this corner case? As a side note I did not run the tests as no change to the code was done 🙏

Core_Animation_Path_Issue.json
cc: @wzxha

[calda]

Thanks for the detailed investigation!

I tend to agree that this is not going to be fixable to due the architecture of the CA engine. If we document this general issue (that the CA engine doesn't support some types of intersecting / subtracting shape configurations) somewhere like the Lottie Documentation (https://lottie.airbnb.tech/#/ios / https://lottie.airbnb.tech/#/supported-features) then we could close these issues as expected behavior.