New update system

Created by: Durman

Addressed problem description

This is third attempt - #3179 #2393 I fill this will be last one.))

Closes #3058 (closed) Closes #3795 (closed)

New features

• It will be possible to cancel node tree updating But not always. It can cancel only between nodes but not when a node is working. It is more flexible with node groups. It will possible to evaluate them one by one internal node so in this way work of a group node can be canceled. Evaluation can be canceled by pressing escape but also it is possible by changing a node value before a tree is fully evaluated. In this case the change of the property will cancel current evaluation and start new one. Also canceling is possible during animation (the same way as with property changed) but probably it is not always expected and there should be an option.

• If a node tree has more then one disconnected node graph they will be evaluated independently. It means that an error in one subgraph does not prevent updating of another. Also error messages will be more persistent and wont disappear until the cause to be resolved. But there is also another side effect. Nodes will be never reevaluated if there is a node with an error before. In current update system in some cases it's possible and I don't know whether I should change the logic here somehow.

• Supporting muted links

• show progress in the header of node tree editor

• support tree annotations inside node groups

• cumulative update time

• Changes in panels

Supporting old features

• wifi nodes

• loop nodes. Actually I would prefer not to touch them but I know that they reuse some code from the update system module and it may appear that they expect the module to be in some state to work correctly. I've checked loop nodes seems there is no need in any changes.

• print timings in a node editor. Just show time of a last update. Can be hidden in the panel of tree properties.

• add profiling

Unsupported old features

• Evaluation order according nodes position. The approach looks doubtful to me. If an order has metter it should be set explicitly with links I think. And would prefer not to overcomplicate the update system. But if some one interested it could be implemented ofcause. In this case new sorting method should be added to the utils/tree_walk.py module. And the event should get extra option I guess.

• Show error stack in a node tree editor. It looks like useless for users and is more needed for devs. I expect last ones use system console for that since there is other useful information there.

• Showing time graph. I would not mind to connect it to new update system but it's not connectable. It uses the update system module directly. Proper place to connect it would be in tree.update_ui method. This is new method called by new update system when the job is done. Updating time can be get from tree.handler.get_update_time(). The only problem will be with evaluation order because it is not kept in statistic results currently but could be added.

• Heat map. It is tightly bound to current update system and can't be reused. Showing update time in a tree editor partly covers this functionality. In the future I have plans of improving debugging tools as well.

Plans for next PRs

After this PR the throttle decorator and context manager will be deprecated. Evaluation of a tree will be in another Python session and it wont be effected by extra updates of a tree. It will be possible to manipulate with sockets more easily for the same reason. When a tree is evaluated the sockets will already be with the correct is_linked state.

Add more functionality for debugging. I'm thinking of adding list widget to the tool panel. It can show list of all nodes in a tree and their updating time. List widget has sorting and filtering UI which will be quite useful to search, for example, slow nodes. A list item is selectable so it will be possible to give extra information about selected node. Probably it could have an operator - "go to selected node".

Add vectorization loop nodes which would include last ideas about how the vectorization should work. Also it should be possible to cancel their work. It should be possible to debug each iteration. Implementing them could be simpler then past the vectorization into all existing nodes.

Think how the work of the socket_data module could be delegated to update system.

Preflight checklist

• Code changes complete.
• Code documentation complete.
• Documentation for users complete (or not required, if user never sees these changes).
• Manual testing done.
• Ready for merge.