Fwd: VTK Timings w/r to OpenGl

[obara]

Hi Bill,

I modified the code to do a glXMakeCurrent call between each display list 
call and there was not much of a  speed impact (< 10% in the 27,000 cube 
test).

Bob

>Did your opengl app call MakeCurrent for each call?
>I think vtk does this. 
>
>
>At 05:43 PM 4/26/00 -0400, you wrote:
>>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.
>>-------------------------------------------------------------------- 
>


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.
--------------------------------------------------------------------