[Paraview] qvtk problems with the pipeline

[Dominik Szczerba]

... having now come back to the original implementation (Update gathers 
parameters, pipeline re-executes always waisting time) I recalled one 
more problem I was having with it before:

vtkStreamingDemandDrivenPipeline (0xa14ee18): The update extent 
specified in the information for output port 0 on algorithm 
vtkExtractVOI(0xa14e760) is 62 325 104 272 88 167, which is outside the 
whole extent 63 324 105 271 89 166.

which is really driving me mad as I can google out absolutely no 
conclusions on this frequently raised issue. Migrating to signal/slots 
resolved this issue (while creating new ones...)

with regards,
Dominik

Dominik Szczerba wrote:
> Clinton Stimpson wrote:
>> On 08/01/2009 05:01 AM, Dominik Szczerba wrote:
>>> Many thanks for the feedback. Pls see below:
>>>
>>> Clinton Stimpson wrote:
>>>> Dominik Szczerba wrote:
>>>>> My pipeline works all right and gets updated on demand properly. I 
>>>>> achieve it by connecting spinboxes/lineedits etc. to functions that 
>>>>> set parameters of my filters before I explicitly hit the final 
>>>>> 'apply' button. The annoying problem is that the pipeline gets 
>>>>> executed also when I interact with the render window (click to 
>>>>> rotate etc.). I did not (intend to) set up such functionality, I 
>>>>> want the pipeline to execute only after an explicit button click 
>>>>> (like in paraview). How do I find out who is triggering the pipeline 
>>>>> behind my back?
>>>>>
>>>>> - Dominik
>>>>>
>>>> ParaView queues up the changes, and only applies them to the filters 
>>>> when the apply button is pressed.
>>>> If you're applying them on the filters when spinboxes/lineedits 
>>>> change, and a menu comes and goes over the graphics view, that could 
>>>> trigger an update you might not want.
>>>>
>>>> How about your apply button gathering the parameters from the widgets 
>>>> on the form and applying them?
>>> That was my original idea and implementation: However, this way the 
>>> WHOLE pipeline ALWAYS gets re-executed. Concrete example pipeline: 
>>> extractVOI->GaussianSmooth. If Apply button gathers the parameters and 
>>> sets them to the filters every time, changing e.g. only smoothing 
>>> params (while keeping the same VOI) still causes both filters to 
>>> re-execute. This should not happen, as VOI should be up to date. The 
>>> same is true for more filters, e.g. Threshold: re-feeding the same 
>>> parameters and/or arrays to process somehow fools the up-to-date'ness 
>>> of the filter. Am I expected to walk around the problem by bookkeeping 
>>> the changing params and the up-to-date'ness myself?
>>>
>>> Note that this is different to paraview, where you have only one 
>>> filter per menu entry and can explicitly request changes. Here I have 
>>> one meta-filter, consisting of several atomic ones.
>>>
>>> After your remark I feel the original approach was the right one. But 
>>> then how do I only request the update if a REAL CHANGE and not only a 
>>> FORMAL SET of parameters is the case?
>>>
>> vtkSetMacro checks for changes before calling this->Modified();  But are 
>> you saying its a problem because not all Set functions check for changes?
> 
> I am saying that (e.g.) setting VOI in vtkExtractVOI or 
> InputArrayToProcess in vtkThreshold to the already previously set values 
> (no factual change, just re-feed of the old ones) triggers the pipeline 
> to re-execute. I do not understand this behavior as I was - as you point 
> out - hoping for the set macros to take care of that.
> 
>> To do your own bookkeeping, one idea is to connect to the QWidget's user 
>> property's notify signal (see QMetaObject::userPropery), and anytime one 
>> of those fires, you add to a list of widgets that have changed.  Then at 
>> apply time, just push those values down.
>>
> 
> A little above my knowledge level but many thanks for the pointers to 
> start with!
> 
> Overall, many thanks for valuable insights.
> 
> -- Dominik
> 
>> Clint
>>
>>
> 
> 


-- 
d o m i n i k   s z c z e r b a ,   p h d . . . . . . . . . . .
c o m p u t a t i o n a l   l i f e   s c i e n c e   g r o u p
. . . . . . . i t ' i s   r e s e a r c h   f o u n d a t i o n
. . . . . . . . . . . . . . . . . . . . http://www.itis.ethz.ch