Re: [PyOpenGL-Users] Suspiciously slow script

[Derakon <de...@gm...>]

I'm including the mailing list again, because at this point it looks
pretty clear that there's something wrong with my PyOpenGL install,
and I have no idea how to figure out what it could be. To recap, we've
tried display lists and VBOs now, and can verify that the same script
running on my machine is slow, while running on Ian's machine it is
fast. The script can be downloaded from here:
http://derakon.dyndns.org/~chriswei/temp/test3.py

The image being used as a texture is here:
https://jetblade.googlecode.com/hg/data/sprites/terrain/jungle/grass/blocks/allway/1.png

The task being performed (drawing 400 textured quads) does not require
significant computing power, so hardware should not be an issue (I
have a Radion X1600 with 256MB of RAM, which is entirely capable of
playing modern games).

My PyOpenGL install was created by downloading the PyOpenGL and
PyOpenGL-accelerate packages from
http://pyopengl.sourceforge.net/documentation/installation.html and
doing "python setup.py install". The only problem I ran into there was
that PyOpenGL-accelerate was trying to pass -Wno-long-doubles to gcc,
which didn't recognize it as a valid commandline option. I told it to
use gcc 4.0 instead of gcc 4.2 and it built without complaints.

I thought perhaps the fact that I'm still using Python 2.5 could have
been the problem, so I installed numpy/PyOpenGL/PyOpenGL_accelerate
with Python 2.6 using those same downloads, and that's also slow. I
thought maybe the easy_install instructions could generate a different
install, so I tried those, and it's still slow.

If I remove the GL_TEXTURE_MIN_FILTER line then I get an absurdly fast
(830FPS) set of white rectangles. As I understand it, doing this
causes OpenGL to assume that I'm going to provide mipmaps for the
texture, and since I don't it defaults to white. Which is, apparently,
much easier to draw than the textured quads.

If I switch to RGB instead of RGBA and turn off blending, then it's still slow.

Switching from an 800x600 window to a 400x300 window gets me 104FPS;
likewise, switching to a 1600x1200 window gets me 3FPS.

Here's the output of running PyOpenGL's performance test (from
tests/performance.py); I have no idea how to interpret it.

Count: 256 Total Time for 100 iterations: 0.00929379463196  MTri/s:
2.75452611272
Count: 512 Total Time for 100 iterations: 0.00796604156494  MTri/s:
6.42728255717
Count: 1024 Total Time for 100 iterations: 0.00892996788025  MTri/s:
11.4670065305
Count: 2048 Total Time for 100 iterations: 0.0114290714264  MTri/s:
17.9192160377
Count: 4096 Total Time for 100 iterations: 0.0237309932709  MTri/s:
17.2601287828
Count: 8192 Total Time for 100 iterations: 0.0263659954071  MTri/s: 31.070323246
Count: 16384 Total Time for 100 iterations: 0.0477550029755  MTri/s:
34.3084472394
Count: 32768 Total Time for 100 iterations: 0.0931870937347  MTri/s:
35.1636677213
Count: 65536 Total Time for 100 iterations: 0.188548088074  MTri/s: 34.758241608
Count: 131072 Total Time for 100 iterations: 0.3538210392  MTri/s: 37.0447162488
Count: 262144 Total Time for 100 iterations: 0.695466995239  MTri/s:
37.6932337256

Any ideas? Any additional information I could provide? I'd love to get
this sorted out, as there are things I want to do in this project that
SDL really isn't capable of doing in a remotely timely manner.

Thanks in advance!

-Chris

On Sat, May 22, 2010 at 8:44 AM, Ian Mallett <geo...@gm...> wrote:
> Hi,
>
> Well, modern games don't always use display lists.  Although display lists
> are easy, they're not *technically* allowed.  They're depreciated, but we
> wouldn't be expecting computers to be losing support for them for at least
> another 5 to 10 years.  Maybe ATI is jumping ahead, just to be annoying.
>
> VBOs and vertex arrays are supposed to be supported everywhere.  For your
> convenience, attached is my VBO version of your code (requires NumPy).  If
> anything should make it fast, this should.
>
> Ian
>