I started earlier working seriously on the image handling code (stopped when my hands gave out). At the moment each image-based function needs a special wrapper. There's also dozens of "special" wrappers from PyOpenGL that are really just type-specific versions of the root functions. So far I've just wound up hard-coding each wrapper, I'm hoping that a common pattern will show up before too much cut-and-pasting is done.

Still, the cool thing is that OpenGLContext's image handling is now working under OpenGL-ctypes. OpenGLContext just uses four or five of the most common calls, not really surprising that it can work with the image handling support half-done, but it does make a lot more of the OpenGLContext demos usable.

Images are actually handled through a wrapper around the Array data-type mechanism, so it should be possible to define images with bald integers/floats/longs, Numpy Arrays, ctypes pointers, etceteras. Eventually hoping to add PIL images, PyGame surfaces, wxPython images/bitmaps, PyMedia streams, etceteras so that those types can be used as textures/images without needing an extra copy (as PyOpenGL does currently, (sometimes 2 or 3 copies)).

At the moment there are only two pieces of C code in the OpenGL-ctypes codebase, a function to retrieve the data * from a Numpy array, and another to retrieve the data * from a Python string. Both of those should be doable easily in ctypes, so providing a pure-Python version of OpenGL-ctypes seems like it should be possible. Performance so far isn't abysmal, but it also isn't blowing me away. Will see when we get up to reasonable scenegraphs whether we need to write C versions of the various pieces.

GLUT is still being a serious pain. Will need to sit down and see what's going wrong there. I'm beginning to suspect that it's a platform issue... there's just too many things that are failing deep inside GLUT from seemingly innocuous calls.