diff options
Diffstat (limited to 'source/blender/compositor/intern/COM_ExecutionSystem.h')
| -rw-r--r-- | source/blender/compositor/intern/COM_ExecutionSystem.h | 55 |
1 files changed, 31 insertions, 24 deletions
diff --git a/source/blender/compositor/intern/COM_ExecutionSystem.h b/source/blender/compositor/intern/COM_ExecutionSystem.h index 55c2ed6c22b..009b1fb28cd 100644 --- a/source/blender/compositor/intern/COM_ExecutionSystem.h +++ b/source/blender/compositor/intern/COM_ExecutionSystem.h @@ -30,12 +30,13 @@ class ExecutionGroup; /** * \page execution Execution model - * In order to get to an efficient model for execution, several steps are being done. these steps are explained below. + * In order to get to an efficient model for execution, several steps are being done. these steps + * are explained below. * * \section EM_Step1 Step 1: translating blender node system to the new compsitor system - * Blenders node structure is based on C structs (DNA). These structs are not efficient in the new architecture. - * We want to use classes in order to simplify the system. - * during this step the blender node_tree is evaluated and converted to a CPP node system. + * Blenders node structure is based on C structs (DNA). These structs are not efficient in the new + * architecture. We want to use classes in order to simplify the system. during this step the + * blender node_tree is evaluated and converted to a CPP node system. * * \see ExecutionSystem * \see Converter.convert @@ -43,35 +44,41 @@ class ExecutionGroup; * * \section EM_Step2 Step2: translating nodes to operations * Ungrouping the GroupNodes. Group nodes are node_tree's in node_tree's. - * The new system only supports a single level of node_tree. We will 'flatten' the system in a single level. + * The new system only supports a single level of node_tree. + * We will 'flatten' the system in a single level. * \see GroupNode * \see ExecutionSystemHelper.ungroup * - * Every node has the ability to convert itself to operations. The node itself is responsible to create a correct - * NodeOperation setup based on its internal settings. - * Most Node only need to convert it to its NodeOperation. Like a ColorToBWNode doesn't check anything, - * but replaces itself with a ConvertColorToBWOperation. - * More complex nodes can use different NodeOperation based on settings; like MixNode. - * based on the selected Mixtype a different operation will be used. - * for more information see the page about creating new Nodes. [@subpage newnode] + * Every node has the ability to convert itself to operations. The node itself is responsible to + * create a correct NodeOperation setup based on its internal settings. Most Node only need to + * convert it to its NodeOperation. Like a ColorToBWNode doesn't check anything, but replaces + * itself with a ConvertColorToBWOperation. More complex nodes can use different NodeOperation + * based on settings; like MixNode. based on the selected Mixtype a different operation will be + * used. for more information see the page about creating new Nodes. [@subpage newnode] * * \see ExecutionSystem.convertToOperations * \see Node.convertToOperations * \see NodeOperation base class for all operations in the system * * \section EM_Step3 Step3: add additional conversions to the operation system - * - Data type conversions: the system has 3 data types COM_DT_VALUE, COM_DT_VECTOR, COM_DT_COLOR. - * The user can connect a Value socket to a color socket. - * As values are ordered differently than colors a conversion happens. + * - Data type conversions: the system has 3 data types COM_DT_VALUE, COM_DT_VECTOR, + * COM_DT_COLOR. The user can connect a Value socket to a color socket. As values are ordered + * differently than colors a conversion happens. * * - Image size conversions: the system can automatically convert when resolutions do not match. * An NodeInput has a resize mode. This can be any of the following settings. - * - [@ref InputSocketResizeMode.COM_SC_CENTER]: The center of both images are aligned - * - [@ref InputSocketResizeMode.COM_SC_FIT_WIDTH]: The width of both images are aligned - * - [@ref InputSocketResizeMode.COM_SC_FIT_HEIGHT]: the height of both images are aligned - * - [@ref InputSocketResizeMode.COM_SC_FIT]: The width, or the height of both images are aligned to make sure that it fits. - * - [@ref InputSocketResizeMode.COM_SC_STRETCH]: The width and the height of both images are aligned - * - [@ref InputSocketResizeMode.COM_SC_NO_RESIZE]: bottom left of the images are aligned. + * - [@ref InputSocketResizeMode.COM_SC_CENTER]: + * The center of both images are aligned + * - [@ref InputSocketResizeMode.COM_SC_FIT_WIDTH]: + * The width of both images are aligned + * - [@ref InputSocketResizeMode.COM_SC_FIT_HEIGHT]: + * The height of both images are aligned + * - [@ref InputSocketResizeMode.COM_SC_FIT]: + * The width, or the height of both images are aligned to make sure that it fits. + * - [@ref InputSocketResizeMode.COM_SC_STRETCH]: + * The width and the height of both images are aligned. + * - [@ref InputSocketResizeMode.COM_SC_NO_RESIZE]: + * Bottom left of the images are aligned. * * \see Converter.convertDataType Datatype conversions * \see Converter.convertResolution Image size conversions @@ -79,8 +86,8 @@ class ExecutionGroup; * \section EM_Step4 Step4: group operations in executions groups * ExecutionGroup are groups of operations that are calculated as being one bigger operation. * All operations will be part of an ExecutionGroup. - * Complex nodes will be added to separate groups. Between ExecutionGroup's the data will be stored in MemoryBuffers. - * ReadBufferOperations and WriteBufferOperations are added where needed. + * Complex nodes will be added to separate groups. Between ExecutionGroup's the data will be stored + * in MemoryBuffers. ReadBufferOperations and WriteBufferOperations are added where needed. * * <pre> * @@ -127,7 +134,7 @@ class ExecutionSystem { */ Groups m_groups; - private: //methods + private: // methods /** * find all execution group with output nodes */ |