Hi Mike! Will PyOpenGL 3.x be rewritten in the future to use SWIG, Pyrex or Python extensions written in C to improve performance? Is there a possibility of mixing ctypes with Python extensions in C for the more critical parts?
/Peter On 2009-04-01 (Wed) 17:48, Mike C. Fletcher wrote: > PyOpenGL is the traditional OpenGL binding for the Python language > (Python 2.x series). This release is the first major release of the > package in more than 4 years. PyOpenGL 3.x is a complete rewrite of the > PyOpenGL project which attempts to retain compatibility with the > original PyOpenGL 2.x API while providing support for many more > data-formats and extensions than were wrapped by the previous code-base. > It attempts to retain the "easy" approachable API of the original > PyOpenGL bindings, focusing more on ease of development (both for client > code and the library itself) than speed. > > Build and installation has been dramatically simplified. It is possible > to work directly from a PyOpenGL bzr branch or to merely unpack the > package into your PYTHONPATH. To install from source and/or participate > in development: > > bzr branch lp:pyopengl > bzr branch lp:pyopengl-demo > > then add the pyopengl/OpenGL directory to your PYTHONPATH. You can also > download the source distributions from: > > http://pyopengl.sourceforge.net > > and use standard distutils commands to install. PyOpenGL 3.x is already > supported by the PyInstaller "exe" packaging utility, and can be made to > work with Py2exe with inclusion statements. > > PyOpenGL may be installed using the easy_install script if desired. > There are no setuptools/package-resources dependencies in PyOpenGL 3.0.0 > final. You can install PyOpenGL on supported platforms (currently > Linux, Win32 and OSX) with the following if you have setuptools, PIL and > Numpy installed: > > easy_install PyOpenGL > easy_install PyOpenGL-Demo > > You can then run the scripts in the PyOpenGL-Demo package. > > PyOpenGL 3.x introduces package-level configuration flags which allow > you to modify the behavior of the entire PyOpenGL package, e.g. by > introducing extremely verbose logging, or turning off all error-checking > to improve performance. Of particular note is a flag which allows you > to disable APIs which have been deprecated by the ARB in OpenGL 3.0. > Other flags allow you to control the trade-off between ease-of-use and > performance during the development and release process. > > PyOpenGL 3.x provides access to the entire OpenGL 3.0 API, as well as > most extensions which have been entered in the OpenGL extension > registry. Commonly used extensions can have "Pythonic" wrappers written > easily, and many of the commonly used extensions already have simplified > APIs provided. It also provides wrappers for the GLUT, GLE and GLX > libraries. The AGL and WGL modules are not provided with PyOpenGL 3.x, > as most devs are using window-manager-based GL operations. > > PyOpenGL 3.x provides a simple plug-in API that allows you to write > data-format or platform plugins. These can be used to easily add > "native" support for your array-friendly data-formats (vector classes > and the like). There is a sample data-format plug-in which wraps the > "Vertex Buffer Objects" extensions (in the OpenGL/arrays/vbo.py module). > > PyOpenGL 3.x's documentation has been regenerated and the build process > for the documentation has been updated so that it can be easily > regenerated to include pointers to other Open Source PyOpenGL project's > online code viewers. If you would like to add your project to the list > of referenced projects, please contact the author with details of your > code viewer's url, code license and project name. > > Notes in the reference documentation indicates the deprecated entry > points for OpenGL 3.0. If you have a PyOpenGL code-base you should be > looking at reworking the code in order to eliminate the use of "legacy" > APIs before OpenGL 3.1 drivers become mainstream. At minimum you should > be converting away from per-vertex operations and the use of display > lists toward using array-based geometry. > > 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. If your code is performance critical you should likely use the > accelerator module when it becomes available. 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. > > The 3.0.0 final release has a few bugs fixed from the previous 3.0.0c1 > release. Users of the release candidate should upgrade. PyOpenGL 3.0.0 > is intended for use with the Python 2.x series, porting to Python 3.x is > not currently on the roadmap. There will likely be a PyOpenGL 3.0.1 > release in the near future which will introduce a few more optimizations > and likely will be synchronized with the first public release of the > accelerator modules. > > 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. > > Enjoy yourselves, > Mike > > -- > ________________________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://www.vrplumber.com > http://blog.vrplumber.com
