Duh! OpenGL bug squished...

Saw strange performance show up during testing of a simple set of shader-based samples in OpenGLContext.  Discovered what seemed to be a memory leak of the wrapper objects in OpenGL_accelerate... investigation showed that the wrapers were re-"compiling" the finalized versions of the functions on every call.  Turns out that setting self.__class__.__call__ doesn't alter future calls to the instance?  Or maybe it's just that it doesn't work when you use staticmethods... will need to figure that out at some point.

Other than that, got the OpenGL presentation down to approximately the set of ideas I want to present during the talk, continuing work on making graphics for it, and I'm trying to put together sample code such that most of the features of shaders can be seen relatively easily.  I'm expecting I'll continue playing with it right up until Saturday night.

Along the way have added texture uniform support to OpenGLContext (floats/matrices were already there).  Next up there is to add vertex-attribute support (i.e. arbitrarily specified geometry), which is mostly just a matter of figuring out how to make the nodes work (the attributes work just like the uniforms, so no big deal there). At some point I should also add 3D texture support.

Tomorrow after work I'm going to switch back to the profiling talk (since it's on Friday).  That's mostly just needing polishing and rehearsal, but hey, that's important stuff :) .  I've got all of Thursday "off" save the plane trip to Chicago, so lots of time to tweak and poke and prod.


  1. Marius Gedminas

    Marius Gedminas on 03/24/2009 6:17 a.m. #

    IIRC Python all the special methods (such as __call__) are stored in the C type struct members during class creation time, so you cannot change them afterwards. I'm trying to find a sentence confirming that in http://docs.python.org/reference/datamodel.html#special-method-lookup-for-new-style-classes and failing, so I could be wrong.

Comments are closed.


Pingbacks are closed.