Reduce Reanimated serialization traffic#6219
Conversation
|
mozzius
left a comment
There was a problem hiding this comment.
Appears to double my framerate as far as I can tell! Great work
This is a major footgun with Reanimated, I'm shocked this makes such a difference. I think the makeMutable code is good, since it's outside of a component it's fine to not cancel/clean up
|
You only need to call cancelAnimation() when you actually animate with the value, can be skipped if not used for animation. Great find! |
|
For posterity, Reanimated fixed this upstream in software-mansion/react-native-reanimated#6758 which I assume went out in 3.17.0 |
|
Nice! I'll see about reverting this then |
|
no worries, we already did the revert :) i just linked to this PR from somewhere and then realized it’s not very clear that the upstream issue was fixed |
|
Ahh :) nice |
This was a major WTF moment for me and I'm still not sure to what extent this is actually useful. However, the Android GPU profiler seems to be happy about this change.
There is some information about how Reanimated closures work here: software-mansion/react-native-reanimated#3670 (comment)
We're closing over
withSpringwhich I assume means that this clone function will have to go intowithSpringitself, deal with its closures over top scope, and so on. I haven't tried logging what's going on there but I suspect there may be some serialization overhead.However, we can just create initial and final values of the animation and expose those to the worklet. I didn't expect this to be faster but it does seem to be. Or maybe the GPU debugger is being misleading.
Test Plan
Enable GPU profiler, build for release on device, remove all embeds (they add too much other unpredictability), continuously scroll a little bit up and down with your finger without releasing on Home.
Before
Overall we're way above the red line.
The green+blue stuff reaches the green line.
After
Overall we're a bit below the red line.
The green+blue stuff is halfway within the green line.