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 ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
