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] <roeb...@gmail.com> 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 > <br...@hamsterrepublic.com>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.schill...@gmail.com> 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. >>>>> >>>>> >> >
