Add support for nodes as functions

[chrfalch]

Motivation

When creating multiple dynamic animations with react-native-reanimated the number of nodes that needs to be transported over the bridge is a performance challenge. One of the limitations of the current primitives offered by reanimated is the lack of function nodes. Being able to define node trees that can be reused will offer better performance. A previous attempt has been done in this pull request: #42

Implementation

The suggested implementation tries to limit changes to the current source code by adding new nodes without changing the existing implementation too much. Three new nodes have been added:

• ParamNode
• CallFunctionNode
• FunctionNode

A few changes to the NodeManager to be able to force reevaluation when calling functions have been added.

The implementation uses a simple proc function in Javascript to create function nodes. Following is an example of how a function is defined and used.

// Defining the function
const mulXY = proc((x, y) => multipy(x, y));

// Using the function
const myX = new Animated.Value(12);
const myY = new Animated.Value(14);
const myResult = mulXY(myX, myY);

Technical

The solution I have used in this implementation is to implement the ParamNode as a node that holds a reference to other nodes - returning the referenced node's value when evaluated and setting the referenced node's value when changed.

Calling the function node is done using the CallFuncNode that is created when calling the function (on the JS side). When the CallFuncNode is evaluated, it performs the following steps:

1. Start a new context
2. Copy current argument nodes to the param nodes (using a Stack in the param node)
3. Evaluate the function node's expression
4. Pop the current argument nodes from the param nodes
5. End context

I have also changed NodeManager's invalidate strategy so that it will force a reevaluation of nodes when we are in a function call to avoid returning the same value for multiple functions calls with different parameter references.

Using a stack in the ParamNode ensures that we can create recursive functions.

Memory

A single proc node should be created as a global constant in javascript since they are immediately attached and will never be removed.

Platforms

Both Android and iOS platform-specific code has been added in addition to the required JS code.

Further plans

Rewriting functionality in reanimated called often should be considered. Moving complex spring functions to functions could also be considered but is not necessarily part of this PR.

Testing

Convert built-in derived functionality to use proc nodes and verify that all examples work nicely. I have already done this for interpolate and easings and it seems to be working fine. Verify that no memory leaks exist.

I believe that the current implementation supports caching of function evaluation - would be happy if someone else could confirm this.

[osdnk]

It's lovely! I truly appreciate it and I'll do my best to merge it. Its also big problem in react navigation which is a bit blocking for us!

[osdnk]

maybe we can pass context here? And then taker advantages of memoization per context?

[chrfalch]

I really didn't want an external evaluation context.... To try to avoid changing too much of the code - what is the evaluation context anyways? :) What I'm using is the param node that wraps another node - and for each function call it's inner node is switched to the id of the current parameter. This way things will be correct. We only need to ensure that calling the same function twice (recursive), the function should be evaluated each time.

[chrfalch]

Why?

…

28. jul. 2019 kl. 19:04 skrev Michał Osadnik ***@***.***>: @osdnk commented on this pull request. In android/src/main/java/com/swmansion/reanimated/UpdateContext.java <#354 (comment)>: > @@ -7,6 +7,7 @@ public class UpdateContext { public long updateLoopID = 0; + public long contextCount = 0; public final ArrayList<Node> updatedNodes = new ArrayList<>(); Shouldn’t updatedNode be also context-related? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#354>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGVV5EVFRPH5OVVZAI5YETQBXGRBANCNFSM4IHMOWSA>.

[osdnk]

https://github.com/kmagiera/react-native-reanimated/pull/354/files#diff-bea77be6106929c0a522d83e3bcdc3beR104

Take a look here please. We currently consider all Call nodes as children of Function node. So if one input (Param node) of Call node is updated, all final nodes (i.e. views) which use this Function node in tree will be marked as updated and evaluation will be performed for all of them. It's not acceptable because only one of final node should be usually marked as updated.
Take a look: Let's assume that A is updated and A is some value related to param P in some context (let's call this context X). F is a function, which is consumed by C1 and C2, but X is only important in for C1, not C2. V1 and V2 are views

A  
|
P
|
...
|
F
|  \
C1 C2
|  |
V1 V2

In your implementation C2 will be also marked as updated.

Please try to dig into evaluation mechanism. I help with assistance!

[chrfalch]

Thanks for the thorough explanation. I think my implementation is a little bit different than what your are describing:

1. Register a param with the param function.

This is a simple node that will be considered a child of the function node.

2. Register a function node using the proc function with the expression to be evaluated and the defined param from the previous step. This node attaches and creates the node instantly with its children.

The JS-call for creating a proc node (the proc function) will return a new js-function that "invokes" the previously defined proc node. When "invoking" the function node you are basically just returning the new function call node - this will be mounted in the view hierarchy - not the function node (the call function node just has a numeric reference to the function onde).

Does this make the implementation clearer?

[osdnk]

Could you please draw or describe what will happen if we will have two views relying on one on a Function which accept one input node (one param)?

[osdnk]

Ohhh, so call is a direct child of params' inputs. Nice idea! Got it!

I wonder, if we can somehow manually drop this function from native side if it will not be used any longer and then attach it manually if needed? What do you think about it? I'll happily see some imperative attach and detach and if it won't be attached by user (with imperative API), then attach it in fist invoke of some call consuming this function. I can imagine a case (e.g. in React Navigation), when we want to prepare this nodes structure somewhere in global scope, then attach it imperatively.

Also, how about this API:

proc((a, b) => multiply(a,b))

How to type it then in TS?

[satya164]

I agree with @terrysahaidak. Currently everywhere I use reanimated, I have to implement some kind of memoization to avoid perf issues, and even then they aren't completely gone. This feature will help a lot with that.

[osdnk]

I agree with everyone, but I want to exclude it from scope of this PR. Let’s discuss, but I’m afraid of blocking this change with discussions over usages of already workable and usable code :)

[terrysahaidak]

@osdnk Let's merge it then and we will test it out :)

[ddzirt]

Well, my current use case is a onboarding transition between images, changing image and text while staying on the same screen and on reaching end triggering another set of animations. It has to run on timeout and with gestures. So I do wish to do this with reanimated and rngh, which I am attempting right now. Still, on Android it is beyond bad. Since I have at least 20 nodes that need init and running straight afterwards init and all that has to happen right after splash animations are done.

[chrfalch]

I think I might have discovered a bug in the memoization code:

const interpolate = proc((a) => add(a, 10));
const setValue = proc((a) => interpolate(a));

export default class Example extends Component {
  render() {
    return (
      <View>        
        <Animated.Code>
          {() => block([
            call([
              setValue(10), 
              setValue(20)
            ], 
            (args) => console.log("value", args[0], args[1]))
          ])}
        </Animated.Code>
      </View>
    );
  }
}

Expected output: 20, 30
Actual output: 20, 20

This is probably happening since in the evaluation the interpolate proc is called twice, and since it wraps the same node id it will return the memoized value. Should this kind of proc be valid, @osdnk ?

[kmagiera]

very happy about the progress on proc nodes. Left a few comments inline

[osdnk]

So excited!