Add platformConfig to native animations and nodes #32736
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
facebook-github-bot
added
CLA Signed
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D32988285 |
react-native-bot
added
the
Type: Enhancement
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D32988285 |
1 similar comment
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D32988285 |
Base commit: 5fa3807 |
Base commit: 5fa3807 |
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D32988285 |
Summary: Pull Request resolved: #32736 The ability to pass an additional property bag to further configure NativeAnimated is useful for a few reasons, e.g., experimentation with multiple implementations of the NativeAnimated module. The specific use case this solves is on react-native-windows, where there are two underlying animation graph options, one "optimized" animation graph that uses UI.Composition, and another similar to the approach to iOS and Android that uses a frame rendering callback. The platform configuration can be supplied to the animation node when `useNativeDriver` is set to `true`, and we pass the platform configuration object to the connected AnimatedValue and all it's children. Changelog: [General][Added] - Option to supply `platformConfig` to NativeAnimated Reviewed By: yungsters Differential Revision: D32988285 fbshipit-source-id: 9aa885e158bad4858237a804ccf8b556790d0e15
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D32988285 |
Collaborator
|
This pull request was successfully merged by @rozele in 4a227ce. When will my fix make it into a release? | Upcoming Releases |
rozele
added a commit
to rozele/react-native-macos
that referenced
this pull request
Sep 16, 2024
Summary: There's an interesting behavior in Animated where we effectively perform an O(N + M) traversal of the Animated graph, calling `__makeNative` on each "input", which in turn tends to call `__makeNative` on each "output" (so we revisit the current node M times when calling `__makeNative` on the M inputs). In practice, the behavior is still O(N), because M is small and finite (most Animated nodes have 1 or 2 inputs). All that said, some platforms (e.g., react-native-windows) rely on this revisiting behavior, where on the first visit, we recurse the node to its inputs, and on the subsequent visit, we update the `_platformConfig` value without recursion (see facebook#32736 for the original change adding platformConfig). A recent change to AnimatedWithChildren (facebook#46286) eagerly invokes `__getNativeTag` on AnimatedWithChildren in the initial recursion step, which forces materialization of the NativeAnimated node *before* it's `_platformConfig` is set. There is certainly some refactoring that needs to be done to improve all this, but for now, this change reverts to delay the call to `__getNativeTag` until after at least one `__makeNative` occurs on an input. Differential Revision: D62768179
rozele
added a commit
to rozele/react-native-macos
that referenced
this pull request
Sep 16, 2024
Summary: Pull Request resolved: facebook#46524 There's an interesting behavior in Animated where we effectively perform an O(N + M) traversal of the Animated graph, calling `__makeNative` on each "input", which in turn tends to call `__makeNative` on each "output" (so we revisit the current node M times when calling `__makeNative` on the M inputs). In practice, the behavior is still O(N), because M is small and finite (most Animated nodes have 1 or 2 inputs). All that said, some platforms (e.g., react-native-windows) rely on this revisiting behavior, where on the first visit, we recurse the node to its inputs, and on the subsequent visit, we update the `_platformConfig` value without recursion (see facebook#32736 for the original change adding platformConfig). A recent change to AnimatedWithChildren (facebook#46286) eagerly invokes `__getNativeTag` on AnimatedWithChildren in the initial recursion step, which forces materialization of the NativeAnimated node *before* it's `_platformConfig` is set. There is certainly some refactoring that needs to be done to improve all this, but for now, this change reverts to delay the call to `__getNativeTag` until after at least one `__makeNative` occurs on an input. ## Changelog [General][Fixed]: Order of operations related to platformConfig propagation in NativeAnimated Reviewed By: yungsters Differential Revision: D62768179
facebook-github-bot
pushed a commit
that referenced
this pull request
Sep 16, 2024
Summary: Pull Request resolved: #46524 There's an interesting behavior in Animated where we effectively perform an O(N + M) traversal of the Animated graph, calling `__makeNative` on each "input", which in turn tends to call `__makeNative` on each "output" (so we revisit the current node M times when calling `__makeNative` on the M inputs). In practice, the behavior is still O(N), because M is small and finite (most Animated nodes have 1 or 2 inputs). All that said, some platforms (e.g., react-native-windows) rely on this revisiting behavior, where on the first visit, we recurse the node to its inputs, and on the subsequent visit, we update the `_platformConfig` value without recursion (see #32736 for the original change adding platformConfig). A recent change to AnimatedWithChildren (#46286) eagerly invokes `__getNativeTag` on AnimatedWithChildren in the initial recursion step, which forces materialization of the NativeAnimated node *before* it's `_platformConfig` is set. There is certainly some refactoring that needs to be done to improve all this, but for now, this change reverts to delay the call to `__getNativeTag` until after at least one `__makeNative` occurs on an input. ## Changelog [General][Fixed]: Order of operations related to platformConfig propagation in NativeAnimated Reviewed By: yungsters Differential Revision: D62768179 fbshipit-source-id: ca9d911503e0630bc3a1309b21f9686aa77ac8b9
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary:
The ability to pass an additional property bag to further configure NativeAnimated is useful for a few reasons, e.g., experimentation with multiple implementations of the NativeAnimated module.
The specific use case this solves is on react-native-windows, where there are two underlying animation graph options, one "optimized" animation graph that uses UI.Composition, and another similar to the approach to iOS and Android that uses a frame rendering callback.
The platform configuration can be supplied to the animation node when
useNativeDriveris set totrue, and we pass the platform configuration object to the connected AnimatedValue and all it's children.Changelog:
[General][Added] - Option to supply
platformConfigto NativeAnimatedDifferential Revision: D32988285