[Bf-committers] Replacing BGL with PyOpenGL

Campbell Barton ideasman42 at gmail.com
Tue Apr 8 23:26:35 CEST 2014


On Mon, Apr 7, 2014 at 6:59 PM, Mitchell Stokes <mogurijin at gmail.com> wrote:
> BGL is a Python wrapper for OpenGL that is maintained by Blender.
> Unfortunately, it is stuck on approximately OpenGL 1.1 level features with
> some shader calls also exposed. It could be updated to support newer OpenGL
> features (at least having vertex arrays would be nice), but there really is
> not much need to maintain our own OpenGL wrapper. PyOpenGL[0] supports
> Python 3.3+, and could be used as a replacement for BGL (in other words,
> deprecate BGL and ship Blender with PyOpenGL).
>
> Pros:
>   * Someone else would be maintaining the wrapper
>   * PyOpenGL uses ctypes and the same package can be used for multiple
> platforms
>
> Cons:
>   * Yet another Python package for us to ship with Blender
>   * Adds to Blender's size
>   * Some APIs may need to be updated (bge.texture and Image.gl_load come to
> mind)
>
> What are some other people's thoughts on this?
>
> --Mitchell Stokes
>
> [0] http://pyopengl.sourceforge.net/

Regarding `bgl`, It seems sensible not to maintain our own complete
OpenGL wrapper for Python,
However bgl's small subset of OpenGL seems OK for simple drawing and
Python is not especially fast for advanced OpenGL use (moving lots of
data around) which is why I think we managed OK so far.

One thing which put me off this a bit is PyOpenGL was slow to upgrade
to Python3, if we depend on modules outside Python's official bundle,
then this can become an issue upgrading, near term its not likely to
bite us (PyOpenGL runs in Python3.4x fine).

Checked size, its approx 1mb compressed, 5mb expanded - so not
prohibitively large.


Next steps could be...


review PyOpenGL project:
- how slow are PyOpenGL to upgrade when a new python comes out?
- is using ctypes slower then our CPython wrapper?
- are there any considerations for running inside Blender's OpenGL
context... (maybe PyOpenGL manages state in some way which conflicts
with Blender).
- how stable, well maintained is PyOpenGL? do bugs get fixed?... etc -
see: http://sourceforge.net/p/pyopengl/bugs/?limit=250
- PyOpenGL extends FreeGLUT, GLE and other libs not included with
Blender (probably fine - just need to be sure users of PyOpenGL don't
consider if broken when those libs are missing)


review use in Blender:
- Port 3-5 scripts which use `bgl` to PyOpenGL, see how it goes.
- document differences (bgl.Buffer, bgl.ShaderSource...)
- review with other py devs (will NumPy be required for
multi-dimensional arrays for eg?)


if acceptable:
- add PyOpenGL to http://svn.blender.org/svnroot/bf-blender/trunk/lib/python
- port all scripts included with Blender (probably not so much work)
- deprecate bgl and add warning when importing.


Note: Image.gl_load should be fine, it doesn't have any bgl
integration. Quick check of `bge.texture` looks like its fine too.


@Mike Pan, since bgl is such a limited set of commands, I think
updating scripts won't be such a problem.


More information about the Bf-committers mailing list