Is there a performance loss in reanimated when animating height, width, or any other layout properties?

[swushi]

Hi 👋

I'm wondering if there is a performance loss when animating layout properties such as left, top, height, or width instead of using transform. I'm asking this because with the vanilla Animated API from react-native this is clear. Only some properties are supported by the native driver. I know there are similar concerns on web with CSS.

My question really boils down to.. Which one of these will perform better?

Option A

const A = () => {
  const anim = useSharedValue(0);
  
  const style = useAnimatedStyle(() => ({ height: anim.value }));

  useEffect(() => {   
    anim.value = withTiming(500);
  }, []);

  return <Animated.View style={style} />
}

Option B

const B = () => {
  const anim = useSharedValue(0);
  
  const style = useAnimatedStyle(() => ({ transform: [{ scaleY: anim.value }], height: 500 }));

  useEffect(() => {   
    anim.value = withTiming(500);
  }, []);

  return <Animated.View style={style} />
}

I've started to notice some hitches in my reanimated animations lately, and they are almost exclusively implemented using non-transform properties.

Thanks for all the hardwork on the project, I really love it!

[nandorojo]

My assumption would be yes, simply because a transform/opacity animation lives in isolation and doesn't affect the layout of other elements. I'm not the expert on this, but I would assume transforms are a safer bet on average.

[swushi]

That's my gut reaction as well. I'll plan on creating a benchmark that will provide some clarity on this.

[yoann84]

That's my gut reaction as well. I'll plan on creating a benchmark that will provide some clarity on this.

I'm curious, did you do the benchmark ?
I was planning to use translateY but then if my elements are relative, if I do it on a upper element, I also need to do it on lower elements.

[tomekzaw]

Reanimated splits the animated props into three groups:

• non-layout props, e.g. opacity, backgroundColor, transform
• layout props, e.g. width, height, margin, padding, flex, top, left
• JS props – not related to this topic

When you animate layout props, Reanimated needs to re-calculate the layout of the whole tree on each animation frame, so it's a bit slower than animating only non-layout props.

In some cases, it's possible to avoid layout calculation. For instance, instead of positioning the component relatively using top and left, you can use transform: [ { translateX: left }, { translateY: top } ]. Obviously, this won't affect the position of other components.

[antFrancon]

If this can help someone:
If you absolutely need to animate a layout property such as width or height, use discrete values and then make use of the layout property.

I achieved much better performance with this method when animating the width of a container, for example:

const C: React.FC<{ shrinked: boolean; }> = ({ shrinked, children }) => {
    const animatedStyle = useAnimatedStyle(() => ({
        width: shrinked ? 100 : 250,
     }));

    return (
        <Animated.View style={animatedStyle} layout={LinearTransition}>
            {children}
        </Animated.View>
    );
}

[LeongXianJun]

@MatiPl01 the file you mentioned last year is no longer present in latest main branch
wonder if there is another file that contains the latest listing in the latest main branch?

also, do you think it makes sense to have a dedicated page in the official docs, educating folks on which is the more recommended way/prop/style for animation?

[MatiPl01]

@LeongXianJun

the file you mentioned last year is no longer present in latest main branch

Yeah, we removed this separation of properties and now all properties are updated in the same way via the ShadowTree. We decided to do this because of problems and animation inconsistency when some of properties were updated directly, whilst other ones went through RN's layout calculation before being applied.

wonder if there is another file that contains the latest listing in the latest main branch?

No, now all props are updated in the same way.

also, do you think it makes sense to have a dedicated page in the official docs, educating folks on which is the more recommended way/prop/style for animation?

It might be a good idea to add one but I think that RN in the New Architecture is still changing much between versions and we may do more optimizations in the future so this will likely change quite often.

There is also not a single solution for this as, even though the application of transforms should be faster, because it doesn't affect the layout, it is in fact slower on Android because of how bad is it implemented in the React Native itself and sometimes it might be better to use top/left/bottom/right props to animate the position of the view, for example, when it has the absolute position. There is also one caveat to this rule - it will be faster only if you don't pass the onLayout callback to the component which position you animate with these top/left/... props and any of its children.

As you can see, there are many different cases that may result in a different performance, so I wouldn't like to suggest just one better way as most of the performance difference is the result of how React Native works and this is still changing. I would say that users should try different solution to see which one works best in their case.

[LeongXianJun]

@MatiPl01 good to know that this kinda not an issue with reanimated v4, which my team yet to update with
We are still using v3, so technically, my team can just continue following that list, right?

Of course, my team will still try our best to update all packages (if possible) to the latest stable version.

[MatiPl01]

@LeongXianJun If you are using Reanimated 3 on the New Architecture, then the migration to v4 should be seamless as it works mostly the same as v3.

Of course, my team will still try our best to update all packages (if possible) to the latest stable version.

I don't think that this is necessary. Just make sure that you use a proper RN version and install the correct version of react-native-worklets (see the compatibility table)

[LeongXianJun]

@MatiPl01 thanks a lot for the tips
My team has yet to enable new arch due to the usage of some niche packages
Will try to plan out something on that and hopefully the day won't be too far 🤞🏻