VTK/Executives

From KitwarePublic
< VTK
Revision as of 20:27, 19 June 2009 by Berk (talk | contribs)
Jump to navigationJump to search

Executives:

The class hierarchy for the mainstream VTK executives is as follows.

This is a graph with borders and nodes. Maybe there is an Imagemap used so the nodes may be linking to some Pages.

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:

  1. 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).
  2. 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

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