Re: [pygame] Python - Pygame - PyOpenGL performance

[René Dudfield <renesd@xxxxxxxxx>]

Hi,

I would like to argue that ctypes style extension development is worse compared to C extension development for portability, and maintenance.

There's hardly anyone who knows all the quirks of ctypes, and you still need to test on different platforms.  ctypes doesn't check types for you, so you just get weird errors when your arguments are wrong.  Note, that pyopengl ctypes doesn't magically work on all the different platforms... and still doesn't, it had to be made to work on the various platforms -- and that effort took way longer than the pyopengl C extension.  Also ctypes can not use all C features, so for some APIs it's impossible to write an interface using ctypes.

There are way more people who know how to use C development environments on the order of 1,000,000x as many people compared to the number who know how to use ctypes.  That's the main reason why ctypes projects don't have as many contributors as C extension projects.  A project with one main developer is really poor for maintenance.

Debugging using ctypes is practically impossible - unless you use a debugger from a C development environment.

Ctypes is *not* available on every platform that python is available on.  eg win64, various arm ones, etc etc.  It automatically has worse portability - since it runs on less platforms.


Therefore ctypes has worse portability, and is harder to maintain.






However, I think ctypes is still better compared to swig - just not compared to C extensions.  Since swig is just as bad as ctypes for all the reasons I mentioned above - and has extra badness.  Swig changes over versions, so it's likely your extension will not compile with different versions of swig.  This caused many problems with pyopengl, and took lots of effort to get it working when new versions of swig came out.

On Wed, Mar 18, 2009 at 2:43 PM, Casey Duncan <casey@xxxxxxxxxxx> wrote:

With the emphasis these days on batch operations (VBOs, etc) and doing more and more of the work on the video card itself via shaders, I seriously doubt that the bottleneck of a well-written, modern PyOpenGL application will be the ctypes overhead. The only time I could see that could be would be for immediate mode usage, which is deprecated anyhow, for the simple reason that per-vertex operations no longer mesh well with a modern graphics architecture.

If you are not writing a modern OpenGL app, then by all means, use the old version. It's going to be a while I think before cards drop support OpenGL 2 and earlier features. It will happen eventually though.

There are significant maintenance advantages to ctypes over C-wrappers, generated by SWIG or otherwise. It is difficult to make the latter work well across platforms and python versions. If you've ever looked at the build system for PyOpenGL 2.x, you'd understand what I mean. And this is coming from somebody who enjoys writing C extensions, but for wrapping existing APIs, ctypes is the state of the art. Like Python itself it trades execution speed for development efficiency and better portability.

PyOpenGL is more or less a one man project afaik, and let me tell you, development efficiency rules when you're trying to move mountains yourself.

-Casey

On Mar 17, 2009, at 7:37 PM, Richie Ward wrote:

why did they not make 3.0 with swig?

On Tue, Mar 17, 2009 at 12:26 PM, RB[0] <roebros@xxxxxxxxx> wrote:

http://groups.google.com/group/pyglet-users/msg/832b15389fccd28d?pli=1

Hmm, this is a bit outdated, but I found a few other references that say
SWIG will generally be faster to run, though would have more overhead - so I
dunno.

HTH

On Tue, Mar 17, 2009 at 7:17 AM, RB[0] <roebros@xxxxxxxxx> wrote:

I saw saw tests for performance between the old C PyOpenGL and the new
ctypes one...
The older one was significantly faster from what I saw - but that is how
it will always be - direct usage of a C lib is just like calling C functions
and such - whereas ctypes you have to call a python function (which may call
others) which will execute the C lib code...

I'll see if I can't find the page somewhere...

On Mon, Mar 16, 2009 at 3:44 PM, Brian Fisher <brian@xxxxxxxxxxxxxxxxxxx>
wrote:

That's what PyOpenGL 2.0 was - a C extension instead of ctypes. (made
with SWIG)

I actually still use PyOpenGL 2.0 for reasons other than performance
(py2exe packaging) - I had to build it myself on windows for Python 2.5, you
can get at an installer for it here:
http://thorbrian.com/pyopengl/builds.php

I've never performance tested the difference between it and 3.0 though -
is somebody else could do that, I'd love to see the results

On Mon, Mar 16, 2009 at 10:49 AM, Zack Schilling
<zack.schilling@xxxxxxxxx> wrote:

If someone did this and I could drop it in to my code, that would be
very nice. But for right now, PyOpenGL is serving my needs just fine. I can
use about 600 independently textured and animated sprites onscreen, scaled
and rotated, without stressing a low-end system more than 40%.

On Mar 16, 2009, at 1:00 PM, Forrest Voight wrote:

Would writing a replacement for PyOpenGL in C instead of in Python
with ctypes help? I think it really would ... PyOpenGL is internally
pretty complex, sometimes when I get tracebacks the error is 5 or 6
levels into PyOpenGL. Even a C library that only implemented the
common functions and relied on PyOpenGL for the constants and
functions that do complex things like handling strings would probably
help a lot.

Another way to increase speed is to write an opengl rendering engine
in C and call and make it available as a Python extension. This is
a major speed boost, in particular for a large number of iterations.
Iirc PyOpenGL bindings are generated, many times this is suboptimal
code for what you're trying to do, writing the Python extension in C
manually have been faster for me many times. This is indeed true
if you put your iterations inside a C loop instead of calling the
C function from Python many times.

--
Thanks, Richie Ward