[vtkusers] VTK 4 compatibility removal - update

[Bill Lorensen]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20110509/6f449ab0/attachment.htm>