[prev in list] [next in list] [prev in thread] [next in thread] 

List:       vtk-developers
Subject:    RE: [vtk-developers] Widget redesign
From:       "Dean Inglis" <dean.inglis () camris ! ca>
Date:       2005-09-15 16:27:22
Message-ID: FBEIKIAGJCCFIBIPBIGMEEAICFAA.dean.inglis () camris ! ca
[Download RAW message or body]

Will,

improving widget interactivity (speed) in one of
my medical image analysis applications has involved some
fairly straight forward tweaks/enhancements but I am
still running into situations where bottle necking occurs.
For example, I have a dialog that pops up with
a render window displaying a 2D image and has controls
for drawing: vtkImageTracerWidget, and fitting to an
interactive spline: vtkImageSplineWidget.  The spline widget
is basically vtkSplineWidget but with 2D handles like
vtkImageTracerWidget and a few other bells and whistles.
An "undo" button was added to the dialog so externally
one could do

//start of widget interaction
vtkPolyData* oldpoly =  vtkPolyData::New(); //local poly for shallow copy
m_tracerWidget->GetPath(oldpoly);   //shallow copy
m_undoPoly->CopyStructure(oldpoly); //break it out of the pipeline to
                                    //make it stick with global poly

//later...if we undo
m_tracerWidget->IntitializeHandles(oldpoly->GetPoints());


This involves a lot of copying and consumption if there are many handles.
The faster way to do this is for the widget to maintain a copy of the
handles with an internal vtkPoints or vtkFloatArray:

//in vtkImageTRacerWidget.h

public:
  void RestoreLastRepresentation();
  void RecordLastRepresentation();

  void SetRestore(int restore);
  vtkGetMacro(Restore,int);
  vtkBooleanMacro(Restore,int);

private:
  vtkPoints* LastHandlePositions;
  int Restore;

RecordLastRepresentation() gets called in the OnLeftButtonDown etc. events
(without an external callback tagged to vtkCommand::StartInteraction)
and an undo can be done simply with
m_tracerWidget->RestoreLastRepresentation();

This is something that most if not all widgets should be able to implement,
in my opinion.

Interactivity can also decrease due to a widget's internal
pipeline mechanism(s) for generating its representation.
For example, because a spline widget takes handles and passes those
coords to its vtkParametricSpline ivar (and then to
vtkParametricFunctionSource),
every time a handle is moved during OnMouseMove, BuildRepresentation()
is called wherein the internal splines are re-initialized to re-calculate
their coefficents: lot's of number crunching ensues and if
there are many handles, very slow interactivity.  So far,
I have added a bool variable: FastInteraction, to bypass the
BuildRepresentation() call such that only a picked handle is updated
during mouse movement.  The representation is updated later on
EndInteraction.
A better way to do this, I suppose, would be to either modify vtkSpline
or implement an interpolator such that only "local" coefficents are
re-calculated when the number of interpolating points stays constant.

I haven't tried to convert these over yet to see how optimizations
like the ones above could be done differently...again, I could commit
to the redesign branch for further discussoin/inspection??

Dean



[prev in list] [next in list] [prev in thread] [next in thread]