VTK/Remove VTK 4 Compatibility

From KitwarePublic
< VTK
Revision as of 15:52, 12 August 2010 by Berk (talk | contribs) (Created page with 'One of the main goals of the pipeline re-architecture between VTK 4 and 5 was to move the execution logic from data and process objects to a new set of classes called executives.…')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

One of the main goals of the pipeline re-architecture between VTK 4 and 5 was to move the execution logic from data and process objects to a new set of classes called executives. However, we made certain compromises in order to maintain backwards compatibility with algorithms developed for VTK 4. The most important and damaging of these was keeping the data object as a conduit of meta-data during pipeline passes.

In the old pipeline, algorithms produced meta-data and requests by setting the on the output/input. Something like:

<source lang="cpp"> void ExecuteInformation() {

 this->GetOutput()->SetWholeExtent(...);

} </source>

In VTK 5, the right way of doing this is

<source lang="cpp"> int RequestInformation(vtkInformation*, vtkInformationVector**, vtkInformationVector* outputVector) {

 outputVector->GetInformationObject(0)->Set(WHOLE_EXTENT(), ...);

} </source>

However, the old version still works thanks to the compatibility layer. The code to maintain the backwards compatibility leads to several major problems:

  1. Maintainability of executives and data objects: The executive and data object classes need to contain code to copy meta-data between information objects and data objects at the appropriate times. This code is confusing and hard to maintain as we continue to improve the executives.
  2. Subtle bugs that are very hard to debug: When data objects are used as meta-data storage, do we copy the meta-data when copying the data object? The answer is sometimes. This is hard to explain because it requires a good understanding of the pipeline (specially streaming and parallel execution) but believe me it is a major pain.
  3. Circular dependencies: Data objects are still part of the execution. Therefore, they need to know about executives and algorithms. This creates unnecessary circular dependencies among classes and among objects.

We propose to remove this compatibility layer. It has been a long time since VTK 5 was released. Algorithm and application developers had plenty of time to transition their code to the new pipeline and if they have not transitioned, it means that they are not taking advantage of any new functionality.