[Bf-committers] Compositor tile cache [2/2]
j.bakker at atmind.nl
Tue Jan 29 12:15:05 CET 2013
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
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
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
= 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.
== 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
Jeroen & Monique
- At Mind -
More information about the Bf-committers