Yeh, unfortunately, I haven't found any smart ways to use retained
for 2D graphics engines. Even if you do use VBO's in stream mode you
to update the data every frame, i.e a Python call that makes C
those array structs have to be converted from Python types to C types
eventually as well. Also, changing textures requires immediate mode
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
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.
On 2009-03-17 (Tue) 21:43, Casey Duncan wrote:
With the emphasis these days on batch operations (VBOs, etc) and
more and more of the work on the video card itself via shaders, I
seriously doubt that the bottleneck of a well-written, modern
application will be the ctypes overhead. The only time I could see
could be would be for immediate mode usage, which is deprecated
for the simple reason that per-vertex operations no longer mesh
a modern graphics architecture.
If you are not writing a modern OpenGL app, then by all means, use
old version. It's going to be a while I think before cards drop
OpenGL 2 and earlier features. It will happen eventually though.
There are significant maintenance advantages to ctypes over C-
generated by SWIG or otherwise. It is difficult to make the latter
well across platforms and python versions. If you've ever looked at
build system for PyOpenGL 2.x, you'd understand what I mean. And
coming from somebody who enjoys writing C extensions, but for
existing APIs, ctypes is the state of the art. Like Python itself it
trades execution speed for development efficiency and better
PyOpenGL is more or less a one man project afaik, and let me tell
development efficiency rules when you're trying to move mountains
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 <roebros@xxxxxxxxx> wrote:
Hmm, this is a bit outdated, but I found a few other references
SWIG will generally be faster to run, though would have more
overhead - so I
On Tue, Mar 17, 2009 at 7:17 AM, RB <roebros@xxxxxxxxx> wrote:
I saw saw tests for performance between the old C PyOpenGL and the
The older one was significantly faster from what I saw - but that
it will always be - direct usage of a C lib is just like calling C
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
That's what PyOpenGL 2.0 was - a C extension instead of ctypes.
I actually still use PyOpenGL 2.0 for reasons other than
(py2exe packaging) - I had to build it myself on windows for
Python 2.5, you
can get at an installer for it here:
I've never performance tested the difference between it and 3.0
is somebody else could do that, I'd love to see the results
On Mon, Mar 16, 2009 at 10:49 AM, Zack Schilling
If someone did this and I could drop it in to my code, that
very nice. But for right now, PyOpenGL is serving my needs just
fine. I can
use about 600 independently textured and animated sprites
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
with ctypes help? I think it really would ... PyOpenGL is
pretty complex, sometimes when I get tracebacks the error is
5 or 6
levels into PyOpenGL. Even a C library that only implemented
common functions and relied on PyOpenGL for the constants and
functions that do complex things like handling strings would
help a lot.
Another way to increase speed is to write an opengl
in C and call and make it available as a Python extension.
a major speed boost, in particular for a large number of
Iirc PyOpenGL bindings are generated, many times this is
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
if you put your iterations inside a C loop instead of
C function from Python many times.
Thanks, Richie Ward