[vtkusers] VTK 4 compatibility removal - update

[Berk Geveci]

> Also is there a way that an existing application can
> support these changes and vtk5.8? What will it take to have one code base?

Yes. I am not changing the "new" (>= VTK 5.0) API. I am removing old
(< VTK 5) API. I will add some convenience functions to help folks
with the change but they not strictly necessary. As long as you don't
use these convenience functions, the code that works after my changes
will also work >= VTK 5.0. So there is no issue there.

> I think these drastic changes need to be passed by the VTK ARB.

As for passing these by the VTK ARB, it is already done. Before I
brought this to the ARB, I created this Wiki page:

http://www.vtk.org/Wiki/VTK/Remove_VTK_4_Compatibility

which clearly describes the sort of changes that I proposed. Here is a quote:

"
In the old pipeline, algorithms produced meta-data and requests by
setting the on the output/input. Something like:
void ExecuteInformation()
{
  this->GetOutput()->SetWholeExtent(...);
}
In VTK 5, the right way of doing this is
int RequestInformation(vtkInformation*, vtkInformationVector**,
vtkInformationVector* outputVector)
{
  outputVector->GetInformationObject(0)->Set(WHOLE_EXTENT(), ...);
}
However, the old version still works thanks to the compatibility layer.

...

We propose to remove this compatibility layer. It has been a long time
since VTK 5 was released.
"

The ARB discussed these changes and agreed to them.

> And you know what do do. How will they know how to
> change their classes?

I am taking detailed notes while I work. Once I am done, I will create
a detailed document
describing what needs to be changed and how. The changes I had to make
are trivial for
the most part (but somewhat numerous). To quantify, it took me about
4-6 hours of work
to get Imaging to compile. Imaging has 118 classes (mostly filters)
some of which do nasty
things that I had to fix. Part of this is because I commented out some
functions to redo
code that uses them to do things more cleanly. If I didn't do that, it
would have been less effort.
An application that has some of its own imaging filters and lots of
application logic should be
easy to fix. An application that has lots of nasty filters (i.e.
filters  that depend on the side effects
of VTK 4 pipeline) should have already been fixed because  it would
not have worked properly
with VTK 5. Once I can get the entire VTK to compile, I will fix
ParaView. That will give me
an idea about fixing a non-imaging application. Then I will ask a
Slicer developer to sit with
me to fix at least part of it. I will report on our findings.

If folks have suggestions on how else I can help the community to
migrate to VTK 6, I am
all ears.

-berk


On Mon, May 9, 2011 at 7:24 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> Berk,
>
> This seems like it will have a major impact on customers. If you had to
> change dozens of Imaging classes, just imagine how many of our customers
> will have to do the same. And you know what do do. How will they know how to
> change their classes? Also is there a way that an existing application can
> support these changes and vtk5.8? What will it take to have one code base?
>
> I think these drastic changes need to be passed by the VTK ARB.
>
> Bill
>
> On Mon, May 9, 2011 at 2:22 PM, Berk Geveci <berk.geveci at kitware.com> wrote:
>>
>> Hi folks,
>>
>> I wanted to give you an update on where I am in removing the VTK 4
>> compatibility layer and the issues I have encountered. For reference,
>> see:
>>
>> http://www.vtk.org/Wiki/VTK/Remove_VTK_4_Compatibility
>>
>> Specifically:
>>
>> "Removal of data object's dependency on algorithm and executive"
>>
>> As innocent as this sounds, it is a beast. Below is a list of some of
>> the functions I removed from vtkDataObject.
>>
>> int ShouldIReleaseData();
>> vtkGetMacro(DataReleased,int);
>> void SetReleaseDataFlag(int);
>> virtual void Update();
>> virtual void UpdateInformation();
>> virtual unsigned long GetEstimatedMemorySize();
>> virtual void SetUpdateExtent(int piece,int numPieces, int ghostLevel);
>> virtual int* GetUpdateExtent();
>> unsigned long GetPipelineMTime();
>> void SetUpdatePiece(int piece);
>> void SetUpdateNumberOfPieces(int num);
>> virtual int GetUpdatePiece();
>> virtual int GetUpdateNumberOfPieces();
>> virtual int* GetWholeExtent();
>> void SetExtentTranslator(vtkExtentTranslator* translator);
>> vtkExtentTranslator* GetExtentTranslator();
>>
>> Every single one of the functions above access the pipeline
>> information and hence depend on the algorithm and executive. So what
>> does this mean? It means that if you have a filter that does this:
>>
>> input->GetWholeExtent();
>>
>> it now has to do:
>>
>> inInfo->Get(vtkStreamingDemandDrivenPipeline::WHOLE_EXTENT());
>>
>> If you do:
>>
>> outputData->Update();
>>
>> you now have to do:
>>
>> algorithm->Update();
>>
>> These are all small changes but there seems to be lots of places in
>> VTK that need to be changed. Specially in the Imaging kit. I changed a
>> couple of dozens of classes already. When the entire VTK compiles, I
>> will commit these changes to my Gitorious repo.
>>
>> Also, there are some behavior changes that may require a close look at
>> existing code. For example, vtkImageData::SetScalarType() and
>> vtkImageData::SetNumberOfScalarComponents() currently set meta-data in
>> the pipeline information - vtkImageData does not have a "ScalarType"
>> or "NumberOfScalarComponents" member. I will change these to set the
>> type of the actual scalars, i.e. something like:
>>
>> void SetScalarType(int type)
>> {
>>  vtkDataArray* scalars = vtkDataArray::CreateDataArray(type);
>>  this->GetPointData()->SetScalars(scalars);
>>  ...
>> }
>>
>> With the proper checks, of course. This means that these functions
>> should never NEVER be used in RequestInformation(). As long as they
>> are used in RequestData(), everything should work as before. So this
>> will work as before:
>>
>> image->SetScalarType(VTK_FLOAT);
>> image->SetNumberOfScalarComponents(3);
>> image->SetExtent(...);
>> image->AllocateScalars();
>>
>> -berk
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the VTK FAQ at:
>> http://www.vtk.org/Wiki/VTK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.vtk.org/mailman/listinfo/vtkusers
>
>