Fwd: VTK Timings w/r to OpenGl

[obara]

Hi Folks,

 While working on an application that involve thousands of 
actors in VTK, I noticed really poor graphics performance on a SUN 
Ultra10 Elite 3D workstation for relatively simple geometry.  I then 
began investigating what the performance bottleneck was by writing some 
very simple test applications.  One app was written in VTK and the other 
was written in OpenGl.  Basically each app displays n cubes (each a 14 
point triangle strip) and can change the way the data is structured by 
varying the number of actors (or display lists in the case of OpenGl) 
used as well as changing the material property of each cube.

One using one actor (or one display list) the results are basically the 
same:
#of cubes      framerate      rendering rate
1000      Framerate = 76      .91 MTri/Sec <- limited by frame buffer 
switching
8000      Framerate = 38      3.7 MTri/Sec
15625     Framerate = 25      4.7 MTri/Sec
27000     Framerate = 15      4.9 MTri/Sec

However when I changed the number of actors used (even for 1000 cubes) 
the results differed dramatically:


For 1000 cubes - simply varying the number of actors
actors         Framerate           Rendering Speed
1          Framerate = 76      .91 MTri/Sec <- limited by frame buffer 
switching
100        Framerate = 76      .91 MTri/Sec <- limited by frame buffer 
switching
125        Framerate = 38      .30 MTri/Sec
250        Framerate = 38      .30 MTri/Sec
500        Framerate = 19      .23 MTri/Sec
1000       Framerate = 9.4     .11 MTri/Sec

In the case of OpenGl there was no difference with varying the number of 
display lists (including setting a material property per cube).  The 
Framerate was still 76/sec

In the case of increasing the number of cubes beyond 1000 (each with a 
different material property) using OpenGl:

# of cubes     Framerate           Rendering Speed
1000           Framerate = 76      0.91 MTri/Sec <- limited by frame 
buffer switching
8000           Framerate = 19      1.8  MTri/Sec
15625          Framerate = 9.5     1.8  MTri/Sec
27000          Framerate = 4.8     1.6  MTri/Sec

You can see we are getting at least an order of magnitude penalty.

We also ran both test applications through quantify and saw the following 
behavior:

The expected issue:
There is overhead in vtk itself with so many actors seemingly mainly due
to the fact that it has to poll each actor for changes before it
renders each frame. We are working with Kitware to develop solutions
to this problem.

The unexpected issue:
There is something about how vtk and opengl are interacting that
makes the rendering of the display lists that vtk creates for
the vtkActorTest much slower than for the plain OpenGl code that we 
wrote.

The actual time spent in glCallList for the vtk-based example vs. the 
non-vtk-based example is something like an order of magnitude greater. 

We even tried to allocate (and initializing) blocks of memory between the 
allocations of display lists in the OpenGl example (to simulate the fact
that with vtk the display lists won't be in contiguous memory blocks).
This didn't have any noticable effect.

If anyone have expertise in OpenGl and would like to take a look at why 
the performance differs so drastically please let me know and I can send 
you copies of the test programs.

Please let me know what you think.


Bob



Robert M. O'Bara
Senior Software Engineer
Simmetrix Inc.
1223 Peoples Ave.
Troy, NY 12180

Lab: (518) 276-2867
Main Office: (518) 276-2729

--------------------------------------------------------------------
This is the private VTK discussion list. Please keep messages on-topic.
Check the FAQ at: <http://public.kitware.com/cgi-bin/vtkfaq>
To UNSUBSCRIBE, send message body containing "unsubscribe vtkusers" to
<majordomo at public.kitware.com>. For help, send message body containing
"info vtkusers" to the same address.
--------------------------------------------------------------------