Re: [Paraview] qvtk problems with the pipeline

Dominik Szczerba <dominik <at> itis.ethz.ch>
2009-08-01 11:01:24 GMT

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?
regards,
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
_______________________________________________
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

Re: [Paraview] qvtk problems with the pipeline

Clinton Stimpson <clinton <at> elemtech.com>
2009-08-01 14:56:59 GMT

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?
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.
Clint
_______________________________________________
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

Re: [Paraview] qvtk problems with the pipeline

Dominik Szczerba <dominik <at> itis.ethz.ch>
2009-08-01 17:52:45 GMT

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
_______________________________________________
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