Have been playing with profiles (using RunSnakeRun) of some OpenGLContext VRML viewer runs on real-world-ish worlds. There are a few big hotspots in the OpenGL-ctypes layer:

* wrapper.Wrapper.__call__ — as expected, this is very heavy, as it's doing basically the same work as SWIG does statically at run time. May try choosing specialised versions during finalisation of the wrapper to eliminate the large number of branches in here. About 10s out of a 160s run.

* error.glCheckError — was a little unexpected to see this turn out to be a hotspot, but on looking at the code it makes sense, it's got a number of global namespace lookups, a couple of Python function calls and an attribute lookup and it's called for just about every function in the wrapper. About 5s out of a 160s run.

* glMaterial — is custom Python code doing lots of guessing about the argument types. About 3s out of a 160s run.

* arrays.*.asArray — basically is slow because of the abstraction layers, winds up with 4 or 5 Python attribute lookups and function calls. About 2s out of a 160s run.

Together those account for 1/8th of the run time for the application. That's not too bad, really, given that the functions are also including all of the time to actually do the work, not just overhead. The Alternate Atlas world (which is admittedly fairly simple) runs at about 17fps fullscreen on my (fairly high resolution) desktop while compiling Blender and recording a movie in the background.

Most likely I'll wind up writing parts of the wrapper's __call__ in C (or maybe just common specialised versions of it), will have to look at the other hotspots to see whether writing in C or just writing faster Python is the best approach for them.