[vtkusers] Speeding up Vector Representation

[Obada Mahdi]

Hi Beau,

that sounds like an issue with data preprocessing which is involved when
switching data sets.

On Jan 25, 2006, at 11:20 PM, Beau Sapach wrote:
 > When I change inputs on the vtkGlyph3D to a different dataset  
there is
 > always a slight pause before everything is displayed.
 > [...]
 > My graphics card is just the onboard Intel 82915G card¿ would that
 > make a difference?  The datasets are fairly large, maybe 20,000
 > points.

There are probably plenty of possible reasons for such a behavior, but
here is one thing I would suggest to check first: Do you have "immediate
mode rendering" turned on or off?  If you are not sure, it is most
probably turned off--which is, as I understand, the default setting--and
I suggest that you turn it on, at least for the mapper that processes
your large data set; see `vtkMapper::ImmediateModeRenderingOn()'.

"Immediate mode rendering" means that every time the data has to be
rendered, all rendering primitives are executed "on-the-fly" and fed
into the pipeline of your graphics library (like OpenGL).  The other
method available, which seems to be the default, compiles all rendering
primitives into a more compact form (a "display list", in OpenGL terms),
which, once built and stored, can be executed many times.  For
non-varying geometry, this method generally outperforms immediate mode
rendering; it saves memory bandwidth, and the list might even be stored
in fast video memory.  (However, details on how this is implemented is,
to my knowledge, not part of the OpenGL specification, so I have no idea
whether your hardware and/or rendering library could be a reason for bad
performance.)

So, what might just be happening in your case, is that when changing the
data set, old display lists are discarded and new ones are compiled.
That could use a noticable amount of time, plus there is quite a fast
rendering afterwards, thanks to the display list; sort of a two-way
discrepancy.

However, while enabling immediate mode rendering might help with the
short delay, it will likely have an impact on overall performance.


If that all does not help, you could still try to do some kind of
double-buffering technique, i.e. having two renderers set up and then
switch between them.  I have not done such a thing myself yet, so it is
more a wild guess, but maybe worth a shot.


Regards

Obada