[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Python - Pygame - PyOpenGL performance

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.
> 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