|
|
| (10 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| ==Executives:==
| | #REDIRECT [[VTK/Tutorials/Executives]] |
| | |
| The class hierarchy for the mainstream VTK executives is as follows.
| |
| | |
| <graphviz>
| |
| digraph G {
| |
| fontsize = 12
| |
| fontname = Helvetica
| |
| node [ fontsize = 9 fontname = Helvetica shape = record height = 0.1 ]
| |
| edge [ fontsize = 9 fontname = Helvetica ]
| |
| | |
| vtkExecutive -> vtkDemandDrivenPipeline -> vtkStreamingDemandDrivenPipeline -> vtkCompositeDataPipeline
| |
| [arrowhead=none arrowtail=normal];
| |
| }
| |
| | |
| </graphviz>
| |
| | |
| Below, we provide some information about these executives that is not necessarily found in VTK User's Guide. If you are not familiar with VTK's pipeline execution model, you should read the Managing Pipeline Execution chapter in the book.
| |
| | |
| === vtkExecutive ===
| |
| This class is the superclass for all executives. It is pretty abstract and provides little functionality. Important ones:
| |
| * An executive has an algorithm
| |
| * An executive manages (i.e. has) the input and output information objects of the algorithm. This means that the pipeline graph is stored by a set of executives not algorithms
| |
| | |
| The most important function is vtkExecutive is ProcessRequest(). This method does two things:
| |
| # Forward the request upstream (if the FORWARD_DIRECTION is vtkExecutive::RequestUpstream) or downstream (if the FORWARD_DIRECTION is vtkExecutive::RequestDownstream (note: this is not implemented).
| |
| # Pass the request to the algorithm by calling CallAlgorithm() which calls ProcessRequest() on the algorithm. This can happen before and/or after the request is forwarding depending on whether ALGORITHM_BEFORE_FORWARD and/or ALGORITHM_AFTER_FORWARD is set.
| |
| | |
| CallAlgorithm() calls CopyDefaultInformation() before passing the request to the algorithm. The goal of this function is to copy certain information (such as update requests or meta-information) from output to input (when the algorithm is invoked before forwarding - for example, in REQUEST_UPDATE_EXTENT) or from input to output (when the algorithm is invoked after forwarding - for example in REQUEST_INFORMATION).
| |
| | |
| '''Note on centralized executives:''' This implementation does not allow us to use centralized executives (one executive that manages more than one algorithm) because the executive has an algorithm AND the executive stores the pipeline graph. However, it is possible to create a meta-executive (an executive to rule them all) that is centralized. This executive would have to manage the flow of information itself. This can be done by subclassing the executive class to disable forwarding. The centralized executive can the delegate the handling of each pass to the distributed executives but manage forwarding itself.
| |
| | |
| === vtkDemandDrivenPipeline ===
| |
| | |
| This executive implements a demand-driven (pull) pipeline. It recognizes 3 passes in ProcessRequest():
| |
| | |
| # REQUEST_DATA_OBJECT: This is where the algorithm is supposed to create its output data objects. It is a ALGORITHM_AFTER_FORWARD pass. After forwarding the request upstream, the executive calls ExecuteDataObject() (a virtual member function). This first calls CallAlgorithm() and then CheckDataObject(). If CallAlgorithm() does not create output data objects, CheckDataObject() tries to create them based on a vtkDataObject::DATA_TYPE_NAME defined in the output port information.
| |
| # REQUEST_INFORMATION: This is where the algorithm is supposed to provide meta-data. It is a ALGORITHM_AFTER_FORWARD pass. After forwarding the request upstream, the executive calls ExecuteInformation() (a virtual member function. Note: For backwards compatibility purposes, ExecuteInformation() calls CopyInformationToPipeline() on the output data object. In the old pipeline, the meta-information was provided by setting it on the output data object. This copies such meta-information from the data objects to the output information.
| |
| # REQUEST_DATA: This is where the algorithm is supposed to provide (heavy) data. It is a ALGORITHM_AFTER_FORWARD pass.
| |
| | |
| Implements REQUEST_DATA_OBJECT, REQUEST_INFORMATION and REQUEST_DATA passes.
| |
| | |
| === vtkStreamingDemandDrivenPipeline ===
| |
| Implements REQUEST_UPDATE_EXTENT and REQUEST_UPDATE_EXTENT_INFORMATION (used for dynamic streaming) passes. Introduces concept of extents for structured datasets and piece for unstructured datasets and time steps. Support for extent translator.
| |
| | |
| Talk about streaming
| |
| Talk about parallel processing
| |
| | |
| Streaming in filters (vtkTemporalStatistics - CONTINUE_EXECUTING()), streaming outside filters (vtkPolyDataMapper, looping at the sink)
| |
| | |
| === vtkCompositeDataPipeline ===
| |
| Adds support for iterating over time steps and multiple blocks:
| |
| * If a filter can only handle single block datasets (e.g. vtkDataSet, vtkGraph, ...), this executive can iterate over the blocks of a multi-block dataset and invoke the filter for each block
| |
| * If a filter can only handle one time step and the input has multiple time step, this executive can iterate over the time steps and invoke the filter for each
| |
| * If a reader can only provide one time step at a time and downstream requested multiple time steps, this executive can ask the reader to read each time step and collect the result in a temporal dataset
| |
