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

Re: [pygame] Python - Pygame - PyOpenGL performance



Hi!

Iirc, Pyglet doesn't do animations for textures? That is,
changing the texture based on a preset time scale.

/Peter

On 2009-03-19 (Thu) 08:36, Casey Duncan wrote:
> You should check out how pyglet uses VBOs (and vertex arrays as a  
> fallback) for its batched sprite engine. It also has some pretty keen  
> texture atlas support to reduce texture state changes.
>
> -Casey
>
> On Mar 19, 2009, at 8:03 AM, Peter Gebauer wrote:
>
>> Hi casey!
>>
>> Yeh, unfortunately, I haven't found any smart ways to use retained  
>> mode
>> for 2D graphics engines. Even if you do use VBO's in stream mode you  
>> have
>> to update the data every frame, i.e a Python call that makes C calls, 
>> all
>> those array structs have to be converted from Python types to C types
>> eventually as well. Also, changing textures requires immediate mode  
>> calls.
>> From what little I know about it, my guess is that a C extension is
>> way faster than ctypes and SWIG generated code.
>>
>> SWIG makes sense for an entire scenegraph written in C, the scenegraph
>> is retained in itself and will accept your data, including animations,
>> and continously executing it for you.
>>
>> What most people want is a fast and simple scenegraph, that is  
>> avoiding
>> shaders and the intricate details of opengl.
>> If you have solution for multiple textures in one VBO that does not  
>> use shaders and
>> works in retained mode, please do share. I've been looking for ages.
>> With multiple textures I mean the ability to glBindTexture in retained
>> mode, not the use of multi textures.
>>
>> /Peter
>>
>>
>> On 2009-03-17 (Tue) 21:43, Casey Duncan 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