[Paraview] Question about data (memory) management

[Cornelis Bockemühl]

Thanks for confirming what I assumed but was not able to fully verify
myself!

With that first smart pointer I would not have "dared" to go because I
would now know whether the output data is already managed by some smart
pointer inside the filter. Meaning that the memory would be released once
the filter goes out of scope - with the result that the new smart pointer
would not really have control of that memory! This is why I felt more
"safe" by using one extra data item in my own code.

But now I am taking your word that this is not going to happen. Actually
the memory for the input and output objects seems to be managed by the
caller of RequestData() anyway, no need to manage that memory inside the
function.

Regards,
Cornelis


2017-02-02 15:46 GMT+01:00 Utkarsh Ayachit <utkarsh.ayachit at kitware.com>:

> In general (unless I missed something), it looks fine. A couple of notes:
>
> 1. You don't need to even shallow copy, you can simply save the output
> from any of the internal filters (I typically use a vtkSmartPointer to hold
> on to the reference). e.g.
>
>   vtkSmartPointer<vtkDataObject> intermediaResult = filt1->GetOutput();
>
> 2. You can connect fil1 and filt2 in a pipeline too, to avoid keeping the
> intermediate dataset explicitly:
>
>    filter2->SetInputConnection(filt1->GetOutputPort());
>    filter2->Update();
>    output->ShallowCopy(filter2->GetOutput());
>
>
>
> On Thu, Feb 2, 2017 at 6:42 AM, Cornelis Bockemühl <
> cornelis.bockemuehl at gmail.com> wrote:
>
>> 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(in
>> fo->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
>>
>> _______________________________________________
>> 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 ParaView Wiki at:
>> http://paraview.org/Wiki/ParaView
>>
>> Search the list archives at: http://markmail.org/search/?q=ParaView
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/paraview
>>
>>
>


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