[vtk-developers] Update on VTK 4 compatibility removal

Steve Pieper pieper at ibility.net
Wed Jun 8 09:44:50 EDT 2011


Perfect - thanks.

On Wed, Jun 8, 2011 at 9:24 AM, Berk Geveci <berk.geveci at kitware.com> wrote:
> 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
>>>
>>>
>>
>



More information about the vtk-developers mailing list