Archives week 7 of 2014

Feb. 17, 2014 - Feb. 23, 2014

OSMesa Refactoring

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 ...

Continue reading

PyOpenGL Working on the Raspberry Pi

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 ...

Continue reading

Raspberry Pi BCM Window Needs Love

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 ...

Continue reading

GL Arrogance Cleanup is Significant

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 ...

Continue reading

GL Arrogance

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, ...

Continue reading

More consistency in array input/outputs

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. ...

Continue reading

Daily archives

Previous week

Week 6 of 2014

Next week

Week 8 of 2014

Archives