why did they not make 3.0 with swig? On Tue, Mar 17, 2009 at 12:26 PM, RB[0] <roeb...@gmail.com> 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] <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. >>>>>> >>> >> > >
-- Thanks, Richie Ward