So I wanted to work on a little web-toy that would let kids "hunt" for high frequency words  (basically vocabulary words that need to be immediately recognized) in a field of words. But as they don't necessarily know the words yet, it needs to be something that's read out audibly "Click on <blah>" and then I ran smack into the number of high frequency words in even the first 4 years of school (it's 168 in our school).  That's a lot of words to read out, process, and save just to see if the web-toy is ...

We've had a binding/platform for the Off-Screen Mesa (OSMesa) library for a while now. It was originally coded such that it provided all of the OSMesa entry points from the platform package (not really appropriate, as these are the same level as things such as GLX and WGL). Long story short, they've been moved to OpenGL/osmesa instead. Code that uses OSMesa in PyOpenGL can just update the imports to

# from OpenGL.platform import *
from OpenGL.osmesa import *

to get the entry points that have moved.

So as part of getting a PyOpenGL demo running on the Raspberry Pi I wrote a trivial subset of the Broadcom graphics interface api in ctypes.  There's an (abandoned? not very recent, anyway) full wrapper in Cython, but even getting that compiled just took too long for me working on the Pi (far longer than writing a ctypes wrapper).

The little wrapper module needs work to be usable, but I don't really have the interest needed to do what needs to make it truly useful.  What really seems to be needed is to take the 5 or 6 ...

There were (and still are) lots of places where PyOpenGL code assumed (assumes) that it is running GL. So far my cleanup efforts mean that on importing e.g. GLES1 you don't actually trigger a load of OpenGL. They also mean that most DLLs are lazy-loaded, something that means e.g. GLUT should no longer load on every PyOpenGL import.  However, a lot of the helper code is still GL-arrogant, and that includes such basic things as the array handlers (which import OpenGL to get access to constants, etc) and the VBO module, which has a pluggable implementation, but ...

There are a number of places in PyOpenGL where GL has been arrogantly assumed. In particular, error handling and the shader/VBO convenience code.  The result was that you'd wind up having GL error-checking in GLES or trying to create GL VBOs under GLES. I've done a bit of refactoring to get the error-handling squared away, but the VBO code is going to need a bit of work, as currently it always imports GL and GL ARB implementations, which is not desirable for an ES context. Likely won't get that finished today, though.

Needed an FTP server. 25 lines of code later an FTP server that listens on a particular interface serving files from a given directory, and half of those 25 lines are about processing command-line arguments, getting network addresses and otherwise doing "not FTP" work.

OpenGL often has situations where an argument is actually an output. PyOpenGL has traditionally wrapped those entry points such that they would be removed from the inputs and returned as an output.  I've just checked in code such that for most PyOpenGL entry points you can use either the Pythonic or the C-ish pattern (i.e. if you do not pass in a value, you get a new array, if you do pass in a value, your value is used).

Client code should not require any changes, but it should allow exotic things such as passing in VBOs, memory-mapped ...

I decided to use a USB key root for the RPi, and with that got a standard Raspbian setup going.  The really nice thing is that the EGL, GLES, etc entry points all resolved properly with the same code used for Linux/MESA EGL and GLES, yay.

Thing is, without the broadcom graphics module they're a bit useless, as the EGL Native types are all BCM data-types (I can query configurations, etc, but I can't actually put anything up on screen). There's a Python wrapper for broadcom, but so far it's taken way too long even ...

So Pygame based EGL + OpenGL-ES1 context works with PyOpenGL 3.1 under Kubuntu amd64 with MESA EGL/GLES. Yay.

Really do need to get a couple SD cards ordered so I can port to the Raspberry Pi too. I expect that will be a matter of just getting the proper library-names defined in the platform loading code.  Likely should rename the "egl" platform to "mesaegl" too, as I expect we'll need to differentiate between the various EGL/GLES platforms.

It seems like it might be possible to make an OpenGLContext base context for EGL too (basically a Pygame context ...

PyOpenGL and PyOpenGL_accelerate 3.1.0b1 are now up on PyPI.  There's MS Windows 32 and 64-bit installers for the windows-ians. The main "features" planned for the 3.1.0 release (and available in the beta) are:

• raw wrappers generated from the ARB source XML definitions, this means that it covers a lot more extensions, including GLX, WGL, EGL extensions (partially from Roman Valov)
• heavily restructured internally to make sub-packages less inter-dependent (raw hierarchy is now somewhat self-contained)
• same code-base for Python 2.6, 2.7, 3.3 and 3.4, Python 2.5 is no longer supported, 3 ...