Adds Rendering driver option to NativeAnimated

[rozele]

Description

Type of Change

• Bug fix (non-breaking change which fixes an issue)

Why

Currently, NativeAnimated compiles the animation graph into CompositionAnimations from UI.Composition. While this approach likely provides the ideal performance for native animations on Windows, it suffers a few insurmountable limitations:

1. #8419: Creating a new animation on an animated value after stopping a previous animation on the same value does not retain the current value. a. Even with a fix like #9190, because UI.Composition values cannot be queried synchronously, starting a new animation on an animated value immediately after stopping a previous animation causes jitter in the animation, because it takes 1-2 frames for the completion callback to fire, signaling that the animated value has an up-to-date value.
2. #3283: UI.Composition can only animate supported properties, like opacity and transforms. NativeAnimated provides a prop "hook" (the prop name is progress) to allow arbitrary views to subscribe to animation value changes synchronously. This is not possible with UI.Composition.
3. #4311: Similar to the limitation for starting new animations synchronously after stopping a previous animation on the same animated value (#8419), animated value listeners will always be 1-2 frames out of sync while waiting for an up-to-date composition value. This feature is currently not implemented for the UI.Composition approach, but I suspect it would require a frame callback via CompositionTarget::Rendering, so not only would the values be out of sync, but the approach would have a similar performance profile to the CompositionTarget::Rendering driven animations.
4. #9255: Similar to #3283, it's actually possible to animate arbitrary props with Animated (e.g., borderRadius). It's unlikely that it would be possible to support such an animation with UI.Composition.

There are also a few bugs that are likely possible to workaround for UI.Composition, but would be fixed immediately by this CompositionTarget::Rendering approach:

1. #3460: Animated values persist even after the animation is unmounted with UI.Composition. The CompositionTarget::Rendering approach uses the view's shadow node as the source of truth for the prop value, and resets the prop to null when the animation is unmounted.
2. #9256: The UI.Composition implementation for NativeAnimated commandeers the Offset value for animated nodes, using it to drive progress on an animation. Animated value offsets are not intended for this purpose and can cause bugs as demonstrated in the linked issue.
3. #9251: Calling setValue on an animated value should stop any active animations, but currently does not in the UI.Composition implementation.
4. #9252: Animated.diffClamp nodes are intended to clamp the difference between the last value and the current value, but the UI.Composition clamp expression only has the capability to clamp the current value.
5. #9250: Calling getValue on an animated value does not return the current value for the UI.Composition approach (because values are not available until the animation has been stopped and the completion callback fires).
6. A more minor issue that I haven't filed an issue for, is that Animated.decay animations work slightly differently in NativeAnimated vs. JS-driven animations. The NativeAnimated approach is a bit more "accurate", in that it stops the animation when its value is within 0.1 of the final value if the decay ran infinitely. The JS-driven approach stops the animation more eagerly when the value differential (the difference between the current value and the previous value) is 0.1.

Resolves #3283 Resolves #3460 Resolves #4311 Resolves #5958 Resolves #8419 Resolves #9250 Resolves #9251 Resolves #9252 Resolves #9255 Resolves #9256

What

This change allows each animation node and driver to be used in either composition mode or frame callback / CompositionTarget::Rendering mode. The latter approach is largely derived from the Android implementation of NativeAnimated (and the C# implementation in react-native-windows v0.59 and earlier).

This change will leverage WIP changes to the Animated APIs in RN core that pass a property bag to each AnimationDriver and AnimatedNode signaling which mode to use. The API surface will look something like the following:

const value = Animated.value(0);

Animated.timing(value, {
  ...,
  useNativeDriver: true,
  platformConfig: {
    useComposition: false,
  });

We will also likely complement this API change with a way to set default platformConfig values for all Animated APIs using useNativeDriver: true:

Animated.unstable_setDefaultPlatformConfig({useComposition: false});

For now, in order to not regress performance on existing react-native-windows applications, using the CompositionTarget::Rendering approach will be strictly opt-in. As of this commit, these two approaches cannot be blended together. I.e., you cannot connect a node using UI.Composition to a node using CompositionTarget::Rendering, and it's unlikely these two approaches could be combined until the UI.Composition approach supports synchronous queries of values (at which point, quite a few of the justifications for the CompositionTarget::Rendering approach will be resolved).

Testing

There is no change in the animation behavior before and after this change, as this just sets up for the option to configure the animation type.

Before:

https://user-images.githubusercontent.com/1106239/146243274-da952be7-b098-401d-ad17-c427dc533700.mp4

After:

https://user-images.githubusercontent.com/1106239/146242972-f332afa7-524d-4b75-a59c-8188c749ad13.mp4

Microsoft Reviewers: Open in CodeFlow

Here is a video of composition bugs that are mitigated with tick based animations:

https://user-images.githubusercontent.com/1106239/182472062-05d1daf5-4dbc-42b5-9aea-3de73ce14162.mp4

Notes

Please note, this change leaves the NativeAnimated behavior effectively unchanged - i.e., native animations still default to UI.Composition, and there is no public API surface to allow users to force the CompositionTarget::Rendering driver until #9285 is merged.

[rozele]

FYI - if we decide to move forward with this, I'm working on this PR to RN core, which has good support so far: https://github.com/facebook/react-native/pull/32736, which would allow us to merge without forking so many files from Libraries/Animated in core RN. We'd only need to fork AnimatedPlatformConfig to fix the flow type (assuming that works) and to set the default value we wanted - though we could always set the default value natively.

[agniuks]

FYI - if we decide to move forward with this, I'm working on this PR to RN core, which has good support so far: facebook/react-native#32736, which would allow us to merge without forking so many files from Libraries/Animated in core RN. We'd only need to fork AnimatedPlatformConfig to fix the flow type (assuming that works) and to set the default value we wanted - though we could always set the default value natively.

We'll be reviewing this over the coming week -- curious now that the PR in core RN has been merged, does this need any changes still to account for that? Also out of the merge conflicts, anything non-trivial there? @rozele

[rozele]

@AgneLukoseviciute - I just rebased this on top of @acoates-ms recent migration of NativeAnimated to a TurboModule, so it should be good to go on that front. There's nothing to account for from the PR in RN core. I have already removed the JS changes to Animated that this needed.

[ghost]

Hello @chiaramooney!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.