[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] PyOpenGL Release 3.0.0 (final)
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