Major OpenGL performance hit using Python?

[Mike C. Fletcher]

TheDustbustr wrote:

>I've been messing around with an OpenGL terrain renderer in Python.  Without
>texturing, coloring or lighting, I get 119 frames per second (roughly 2000
>triangles, no frustum culling or LOD).  Compare this to Thatcher Ulrich's
>quadtree demo (written in C++) - Using this to benchmark, I get about 660 FPS
>(thousands of triangles frustrum culled and LOD'ed down to about 2000, with
>texturing and texture lighting).  Both my renderer and Ulrich's use
>glVertexPointer / glDrawElements to submit vertices to OGL.  Obviously, no
>matter how rough the benchmark comparison, my little renderer is running much
>slower.
>
There are conditions where a PyOpenGL renderer can wind up slowing down 
due to excess copying of data.  Check my post to PyOpenGL-users 
yesterday for details about what those conditions are (basically 
mismatching data-types for the array and function and/or non-contiguous 
arrays).

>Is it possible that this performance hit is attributed to Python being slow, or
>am I missing optimizations?  If the former is true, I need to switch to C++
>(however much I dread doing such), because I plan on turning this into a game.
>
A 6:1 ratio for speed is certainly not out of the question as a ratio 
simply for Python overhead.  The best way to find out is to run the 
proggy under profile and see what's actually eating the most time.  If 
all of the time is spent in your geometry-rendering code, you're likely 
looking at a problem with how the data's getting to OpenGL.  If it's a 
wash across everything, you're likely just dealing with a C vs Python 
problem.

HTH,
Mike

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/