[vtk-developers] Update on VTK 4 compatibility removal

Wed Jun 8 09:24:43 EDT 2011

Good point. I moved that link to a new "To be included in VTK 6.0"
section. In all likelihood, there will be a 5.10 release and that will
not include any of these changes. I plan to commit some of the new
convenience functions that I added (backwards compatible) to make it
easier to maintain software that can work both with 5.10 and 6.0.

-berk

On Wed, Jun 8, 2011 at 9:03 AM, Steve Pieper <pieper at ibility.net> wrote:
> Hi Berk -
>
> I didn't find specific mention in a quick review of the posts, but can
> we be explicit that these non-backwards compatible changes will be in
> VTK versions 6.x but not in 5.x?
>
> The main page of the wiki lists this as being in the 'next VTK
> release' which really means next major release, right?
>
> http://www.vtk.org/Wiki/VTK
>
> Thanks,
> Steve
>
> On Tue, Jun 7, 2011 at 5:13 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>> 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
>>>
>>>
>> _______________________________________________
>> 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
>>
>>
>