[vtkusers] [vtk-developers] Update on VTK 4 compatibility removal

[David Gobbi]

Hi Berk,

I can anticipate where these changes might cause tests to fail due to
a couple decade-old changes that I made to VTK/Imaging.  Specifically,
the SetInformationInput() and SetStencil() methods expect pipeline
connections but after your changes, at the very least the tests that
use these methods will have to call Update() on the data manually.

Way back in November I started working to correct the SetStencil()
issue by adding a SetStencilConnection() method, but that never got
past gerrit because I had to switch to other projects:
http://review.source.kitware.com/388

The SetInformationInput() methods are a little trickier, because for
them, I need to be able to establish a pipeline connection that can
pull metadata, but which will never trigger an execute.

Anyway, to get to the point of this email: I'll start looking into
these issues again, this time wrt your code branch, within the next
two or three weeks.

 - David



On Tue, Jun 7, 2011 at 1:52 PM, Berk Geveci <berk.geveci at kitware.com> wrote:
> Hi folks,
>
> I made some more progress on removing the VTK 4 compatibility layer. The
> goals of this work are described here:
>
> http://www.vtk.org/Wiki/VTK/Remove_VTK_4_Compatibility
>
> I am going to regularly send updates to mailing list so that folks can
> try out these changes and see if they need to update their own software. For
> now,  I am publishing a branch called remove-vtk-4-compatibility to
> https://gitorious.org/~berkgeveci/kitware/berkgevecis-vtk. In the
> future, there will be a branch in the VTK stage as well. As of my last
> changes, the entire VTK compiles on my Mac. There are plenty of test failures
> so I wouldn't consider it stable. I would not use it for anything other than
> gauge the progress of the work and to see the changes that are coming.
>
> For a description of my first pass, see my previous e-mail to this list
> title "Started on VTK 4 compatibility removal". My changes in this pass
> (commits 5de4d8854f7e - 4672b5607613a) include:
>
> - I removed the following methods from vtkDataObject (omitting methods
> that are not very relevant):
>
> Update()
> UpdateInformation()
> PropagateUpdateExtent()
> SetUpdateExtent() (all variations)
> SetUpdateXXX() (all variations)
> GetUpdateExtent() (all variations)
> GetUpdateXXX() (all variations)
> SetWholeExtent()
> GetWholeExtent()
> SetMaximumNumberOfPieces()
> GetMaximumNumberOfPieces()
> GetExtentTranslator()
> GetPipelineMTime()
>
> The first 3 of these were the most popular and caused me to update most
> code in VTK. The fixes are pretty simple. This:
>
> filter->GetOutput()->Update()
>
> changed to:
>
> filter->Update()
>
> This applies to Update(), UpdateInformation() and PropagateUpdateExtent().
>
> There was also a lot of this:
>
> filter->GetInput()->Update()
>
> which can now be rewritten as
>
> filter->GetInputAlgorithm()->Update()
>
> The second most popular set was SetUpdateExtent() and GetWholeExtent().
> They are also pretty easy to fix. However, be warned that how to fix it
> depends on the context. If you are in a RequestXXX() method (where XXX
> can be any of Information, UpdateExtent or Data), do NOT call
>
> this->GetInput()->GetWholeExtent()
>
> Instead, do
>
> vtkInformation* inInfo = inputVector[0]->GetInformationObject(0);
> const int* wext = inInfo->Get(
>  vtkStreamingDemandDrivenPipeline::WHOLE_EXTENT());
>
> Similarly, if you are in RequestUpdateExtent or RequestData, do NOT do:
>
> this->GetInput()->SetUpdateExtent()
>
> instead do:
>
> vtkInformation* inInfo = inputVector[0]->GetInformationObject(0);
> inInfo->Set(vtkStreamingDemandDrivenPipeline::UPDATE_EXTENT(), ...);
>
> Alternatively, use the convenience functions defined in
> vtkStreamingDemandDrivenPipeline (look for SetUpdateXXX).
>
> If you are not inside a Request methods, this
>
> filter->GetOutput()->SetUpdateExtent(...)
>
> can now be written as
>
> vtkStreamingDemandDrivenPipeline(filter->GetOutputInformation(), ...)
>
> or
> filter->GetOutputInformation()->Set(
>  vtkStreamingDemandDrivenPipeline::UPDATE_EXTENT(), ...)
>
> This
>
> filter->GetOutput()->GetWholeExtent()
>
> is now
>
> filter->GetOutputInformation()->Get(
>  vtkStreamingDemandDrivenPipeline::WHOLE_EXTENT())
>
> Hopefully, the trend is clear by now. All meta-data and request information
> have to go through information objects using various keys. All methods dealing
> with meta-data and request information were removed from vtkDataObject.
>
> - I changed the signature of all functions dealing directly with
> pipeline information in
> vtkImageData. These include:
>
> SetScalarType()
> GetScalarType()
> SetNumberOfScalarComponents()
> SetAxisUpdateExtent()
> GetAxisUpdateExtent()
> GetScalarTypeMin()
> GetScalarTypeMax()
> GetScalarSize()
> Crop()
>
> These now all take vtkInformation as an argument and made some of
> these static. The most
> common use of SetScalarType() and SetNumberOfScalarComponents() was:
>
> image->SetScalarTypeToFloat();
> image->SetNumberOfScalarComponents(3);
> image->AllocateScalars();
>
> I added a new version of AllocateScalars() to make this easier:
>
> image->AllocateScalars(VTK_FLOAT, 3)
>
> In RequestInformation, you can use the new signatures as follows:
>
> int XXX:RequestInformation(..., vtkInformationVector* outVec)
> {
>  vtkInformation *outInfo = outVec->GetInformationObject(0);
>  vtkImageData::SetScalarType(VTK_FLOAT, outInfo);
>  vtkImageData::SetNumberOfScalarComponents(3, outInfo);
>  ...
> }
>
> This is much easier then setting the values directly in outInfo since
> the keys are
> somewhat elaborate for array meta-data.
>
> Again, the idea is to separate functions that deal with meta-data from functions
> that directly manipulate data.
>
> NOTE: GetScalarType() and GetNumberOfScalarComponents() are still
> available but they
> now work on actual data rather than meta-data. If there are no scalars
> available,
> they will not work correctly. I am comfortable with this change
> because this seems
> to be the only way these methods are used. Please let me know if you disagree.
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>