[Paraview] Question about data (memory) management

[Cornelis Bockemühl]

Dear all,

Would the following construct be safe in terms of proper data handling
inside a filter or would I generate some "unpredictable results", like data
being copied over other data that is still being used?

My purpose is of course to copy data only if it is absolutely required. And
I assume that within the different filters, data are again handled
correctly.

...::RequestData(...)
{
  // get input and output
  vtkPolyData* input0
= vtkPolyData::SafeDownCast(info->Get(vtkDataObject::DATA_OBJECT()));
  vtkPolyData* output = vtkPolyData::SafeDownCast(...);
  ...

  // intermediate data storage
  vtkSmartPointer<vtkPolyData> intermediateData =
vtkSmartPointer<vtkPolyData>::New();

  // first filter
  vtkSmartPointer<vtkSomeFilter> filt1 =
vtkSmartPointer<vtkSomeFilter>::New();
  filt1->SetInputData(input0);
  ...
  filt1->Update();
  intermediateData->ShallowCopy(filt1->GetOutput());

  // second filter
  vtkSmartPointer<vtkSomeOtherFilter> filt2 =
vtkSmartPointer<vtkSomeOtherFilter>::New();
  filt2->SetInputData(intermediateData);
  ...
  filt2->Update();
  intermediateData->ShallowCopy(filt2->GetOutput()); // !!! actually
replacing the input data...

  // some more filters in the same way as filt2 - with always reusing
intermediateData...
  ...

  // return the results
  output->ShallowCopy(intermediateData);
}

Any comments?

Of course I could play safe and

1) replace all "ShallowCopy" with "DeepCopy", and
2) generate an intermediate data object for each and every filter that I am
applying

but this for sure would blow up my memory enormously!

Maybe there is also some document that clearly states what is the proper
"behaviour" inside filters like that, some kind of "code of conduct"
regarding memory management in VTK?

Thanks for any helpful hints!

Regards,
Cornelis

-- 
Cornelis Bockemühl
Basel, Schweiz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20170202/fa74ea47/attachment.html>