[vtk-developers] [vtkusers] VTK 4 compatibility removal - update

[tom fogal]

Attached is a screenshot of VisIt's "VTK upgrade" branch running with 
Berk's new VTK.  Thanks for the help, Berk && Ken.

I started working on it late this morning.  I haven't run it through our 
test suite yet, vtkDebugLeaks is going nuts, and I'm sure there are 
other issues that neither of those will catch.  We also don't use much 
in Imaging/.  Nonetheless I feel that the worries in this thread are 
largely just that -- concerns, but not reality.

One of the things that would have made the transition significantly 
easier is to have the 'vtkXToY' classes added back in, with semantics 
of: deriving from Y, setting 1 input and 1 output port, and setting the 
input port to be of type X.  That kind of translation ended up being the 
bulk of my time on this, such that in retrospect I wish I had either 
written a script for it or just defined those classes myself.

Could you elaborate on a timeframe for merging this, Berk?  Maintaining 
a patch /on top of/ our VTK upgrade branch presents a fairly painful 
logistical issue for me/us.

-tom

On 05/09/2011 05:24 PM, Bill Lorensen 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
>>
>
>
>
> _______________________________________________
> 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
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: visit-with-new-vtk.png
Type: image/png
Size: 77961 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20110516/efddac7d/attachment-0001.png>