Archives October 2012

So as of now I can load Coldshot profiles into RunSnakeRun.  So far they are no more informative than a cProfile profile.  Now the fun part is seeing what kind of tools can actually be fashioned when you have all of this information...

Some ideas

• per-thread views (I think that's a given)
• browse into set of all calls, with calls split up by e.g. bins of run-times
• individual calls by "time line" of calls as a graph of time vs. run-time
• bins of "path" maps of a function (basically see the function calls split by what set of ...

Want to get rid of a CD around the house (who uses CDs any more)?  Pop it into your drive, open it with Dolphin, browse to the 'MP3' (or 'Ogg Vorbis') folder and copy the files to your media directory.  The KDE IO system automatically generates (rips) the "files" when the copying process goes to transfer them.

Now we just need the same thing for DVDs and I might be motivated enough to get rid of *all* the disks. (In case you didn't get the reference...)

Started really looking at the results from Coldshot and realized that the line timings just didn't add up to the function timings... because the line-timings were "localtime" rather than "cumtime".  Local time is actually pretty interesting as a piece of information, but I'm guessing 95% of the time you actually want cumtime when you are looking at a function at the line-profiling level. Will have to add it next week.  Only other major piece missing is the func:func relative time mappings (and function's localtime from that).  Both are loader-side calculations.

Been playing with my experimental profiler (Coldshot) all day.

At this point it can load an OpenGLContext run with 207MB of trace data and produce a basic textual summary (both cProfile-style calls/timing and file:line level timings) in around 4s.  That's still quite slow, as the profiler records around 4MB/second of data, so multi-GB traces seems pretty likely.  The call traces are ~1.5MB/second while the line traces are ~2.5MB/second, so it seems we'll likely want an option to turn off line tracing (and context managers, and a dozen other niceties, I'm ...

So as part of my little Quake 3 BSP loader (twitch) I need to render Quadratic Bezier Spline patches.  I want to do the whole thing from a VBO, so I'm doing the tessellation manually (I also wanted to do it to play).  The basic rendering is now working, that is, I can render a hand-coded QBS into a render-able piece of geometry (in OpenGLContext) with auto-generated normals and texture coordinates.  The BSP format, however, allows the modeller to specify (2) texture coordinates and normals for each control point so that the resulting geometry should cleanly interpolate between those ...

The Pycon.ca schedule is up.  My talk is at 11:20 on Saturday.  It is a revised/extended/updated version of my PyCon 2009 talk on Profiling.

PyOpenGL 3.0.2 (final, finally) has been released. The major changes since 3.0.1 (released in 2010!) are:

• OpenGL core support up to 4.3 level [1]


• OpenGL extension support from the current registry [1]


• Some missing FreeGLUT extensions added


• OpenGL.GL.framebufferobjects providing ARB/EXT alternates for framebuffer operations


• Experimental OSMesa (Offscreen Mesa) context (use the environment variable PYOPENGL_PLATFORM=osmesa)

• Experimental Python 3.2 and PyPy support


• Win64 Support (including OpenGL_accelerate)


• Numarray (the ancient transitional module between Numeric and numpy) is no longer supported as an array type


• More compact auto-generated wrappers


• Large numbers of ...