I’ve got an application that displays vector data over
time. Basically I am using vtkGlyph3D to display the vectors, using a
manually built 2D arrow (just a set of 3 lines). When I change inputs on
the vtkGlyph3D to a different dataset there is always a slight pause before
everything is displayed. Most of the data I need to display is changing
over time, so I’d like to smoothly roll through a set of datasets in this
manner to animate the vector field. Does anyone have any suggestions for
speeding things up??? My graphics card is just the onboard Intel 82915G
card… would that make a difference? The datasets are fairly large, maybe
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
> 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
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
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
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.