[Bf-committers] Compositor tile cache [2/2]

[Jeroen Bakker]

This proposal has been discussed BConf 2012. The buffering between 
frames is not included into this design. The idea of this proposal is to 
buffer tiles from the compositor between changes in the node tree. This 
way the user will get a speed up as not all tiles needs to be 
recalculated. see https://www.youtube.com/watch?v=r5Ggb-ONYDE for prototype.

The "legacy compositor" already had a system for this, but it lacked 
some features:
a. it is not tile based like the new compositor.
b. when reconnecting/adding noodles/nodes all nodes were recalculated.
There are also parts we can reuse:
a. determine where the user modifies a node-setting.

The current system only detects where the modification takes place, but 
not the consequences of this modification. This needs to be part of the 
proposed cache system.

Parts that needs to be designed are:
a. location where the tiles and their states are stored in memory 
between user actions (CACHE).
b. determination and loading of tiles and their state into the 
compositor (LOADING).
c. storing tiles and their state to the cache when compositor is 
canceled or finished (STORING).
d. modification what nodes needs to be recalculated when noodles/nodes 
are modified/created/deleted.

  = Cache system =
The cache will be a class within the Tiles compositor 
(compositor/intern/COM_TileCache.h). Other blender components including 
python won't have access to its data. In the cache all tiles belonging 
to the same execution group will be stored in a single buffer. Per tile 
the state will also be stored (NOT_SCHEDULED/SCHEDULED/EXECUTED). The 
lookup-key of the cache will be the same that is currently used to 
highlight nodes in the node editor.

When de-initializing the compositor, the cache will be cleared. 
(COM_compositor.cpp)

  == Loading ==
When starting the compositor; before grouping the operations into 
execution groups the modification state of the editor node will be 
evaluated. If a node is modified according to this value the operations 
belonging to this node and all operations connected to the output will 
be marked modified. To get this working all operations need to have a 
reference to its editor node.

When the execution groups are initialized, it looks to the last 
operation in its operations-list. If this operation is marked modified, 
it will not load from the cache. Otherwise it will read the buffer and 
state from the cache. Tiles with the SCHEDULED state will be set to 
NOT_SCHEDULED. Only tiles with the EXECUTED states contain usable data.

  == Storing ==
When deinitializing Execution groups the cache will be updated only if 
there are tiles with the state EXECUTED.

  * Noodles *
I assume (but have not investigated) that when noodles are 
created/modified/removed the system just sets all nodes to modified. 
When you know the connected sockets before and after the action you can 
find the actual nodes that needs to be recalculated. Lukas did a patch 
on this, but we need to research how to incorporate it into the 
compositor code.

Regards,
Jeroen & Monique
  - At Mind -