Re: [PyOpenGL-Users] PyOpenGL Release 3.0.0 (final)

[Lorenzo M. <lma...@de...>]

Hello Mike, this really is great news!  Congratulations!


> You should expect a performance decline with the use of PyOpenGL 3.x 
> versus PyOpenGL 2.x!  PyOpenGL 3.x will have an accelerator module 
> released in time to provide better performance, but the development 
> method (ctypes) is inherently slower than the C (SWIG) method previously 
> used.

In the past days I've tried OpenGL_accelerate on some code of mine that 
suffers an expected 50% performance loss switching from pyopengl 2.x to 
3.x, and it already yields a little speedup; since you are speaking in 
future tense, does this mean that more consistent improvements on 
OpenGL_accelerate are planned?

[[Note: the code I'm talking about is heavily display-lists and other 
OpenGL legaciness based, so probably it doesn't represent a valid test 
bench for pyopengl 3.x performance measurements.]]


> Also consider using the 
> package-level configuration flags to remove "support" functionality as 
> you near release, use of these flags can provide more than 2x speedup in 
> most cases.

Are you talking about OpenGL.FORWARD_COMPATIBLE_ONLY?  To do that, the 
OpenGL code in the application must be legacy-free, correct?


> Since the release of PyOpenGL 2.x another common OpenGL binding for 
> Python has become popular and may be an appropriate choice for your 
> projects.  The Pyglet project (http://www.pyglet.org) has a full OpenGL 
> binding in "raw" C style, along with many higher-level utilities to aid 
> in the development of games, all of which can be easily installed on 
> common platforms.

As I wrote in a previous message, such a "raw" C style wrapper is also 
hidden in PyOpenGL, you just have to import from OpenGL.raw.GL instead 
of OpenGL.GL, and switch OpenGL.ERROR_CHECKING to False.

This can improve performance (I get a 100% speedup with the codebase 
mentioned above) and bring it to the levels of 2.x, at the cost of some 
ctypes pollution in the code - raw wrappers of pyopengl and pyglet are 
almost indistinguishable both performance and code appearance wise.


Talking about pyglet, some time ago I happened to read their automatic 
wrapper generator: I found it nice and easily pluggable in a toy project 
of mine.  Since it uses the same ctypes technology and I remember you 
praising it yourself in a past presentation of yours, are you planning 
to merge it into pyopengl3.x to avoid duplicating efforts?


Thanks, and keep up the great work!

-- 
Lorenzo Mancini