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
