Began working on more flags to peel back some of the ease-of-use layers in PyOpenGL to recoup performance. List/tuple array-types now respect the ERROR_ON_COPY flag (effectively disabling list/tuple support when the flag is activated) and there is a STORE_POINTERS flag, which when False (with ERROR_ON_COPY True) will disable wrapper operations storePointer mechanism. That's one stage of 5 wrapper stages. There are three stages that can't be eliminated without overtly changing APIs (the "interpret Python arguments", "expand Python arguments to C-compatible arguments" and "return the correct value" stages).
I worked on eliminating the "convert C-compatible to Ctypes-compatible" stage this morning, and with the two previous optimizations it seems to be a no-brainer (array types have from_param properties, so ctypes will automatically do the operations if the types are already in C-compatible format and aren't temporary objects).
The wrapper code is already Cython-accelerated, so there's no huge need to eliminate the remaining three flags. Still, want to add some code to the wrapper to allow wrappers to drop out of the picture entirely if after all the optimizations are taken into account there's no wrapping left to do.
I'm discovering a small set of cases in OpenGLContext where I was using temporary list/tuple objects as vectors. There is also a case where gluTess* requires doubles, while OpenGLContext now uses floats by default, so a copy was introduced. I'm considering just writing my own tesselation code there.
I'm also beginning to flesh out how I want to do a "Longs Peak-like" rework of the rendering engine, I enabled observation of structural changes yesterday. With that node-paths will be able to watch for changes and the rendering loop can be reduced to a set of rendering tokens which will be fed from the scenegraph, but will be a simple linear loop rather than a complex scenegraph traversal on each frame.
Also fixed a bug with PyOpenGL's Numpy+NURBs introduced by the NURBs error-checking "fix" from the weekend.
Comments
2010-08-31 12:04
That template db idea is prett y neat. I have to say it's get ting pretty annoying downloadi ng database backups and [...]
2010-08-23 20:57
Yeah, in a similar boat with t he code I write... upshot, I'v e got some pretty good compat code in snakeoil, just w [...]
2010-08-22 08:40
Yeah, that's what I started do ing (the function to convert t o bytes), as I support down to 2.4. Thing is this is [...]
2010-08-22 06:28
Your blog aparently likes does n't handle the less than char (<) conversion all that wel l.. everything following [...]
2010-08-22 06:24
The annoying thing about suppo rting both py2k and py3k is th at you wind up having to get r ather explicit about you [...]
2010-08-16 00:48
The measure of a man, I have a lways thought, was - that he l oved. And was loved.
2010-08-15 21:28
Hmm, hadn't realized that was what dpush was for. I guess I 'll have to make the trunk a b ranch rather than a chec [...]
2010-08-15 20:43
For what it's worth, newer ver sions of bzr-svn will not remo ve existing revisions from you r mainline unless you ex [...]
2010-08-15 20:40
bzr-svn supports not inserting any unusual revision properti es, it just means that pushing your bzr revisions into [...]
2010-08-15 18:21
Hmm, maybe I missed something there. Do you mean merge supp ort as in being able to pull f rom N branches into your [...]
2010-08-15 17:45
Lack of merge support kills th e main benefit of bzr-svn over just using svk I'd argue. Personally, I'm *extreme [...]
2010-08-15 11:46
You might want to check out hg subversion
2010-07-25 14:02
> and would have no Trac integ ration The trac-bzr plugin[ 1] seems to provide good integ ration between bzr and t [...]
2010-07-13 21:47
I've always been fascinated wi th the Asterisk AMI interface. So much so that I married tha t fascination with the [...]
2010-07-03 21:32
Yes, only references in dicti onaries are replaced, so hold ing references in lists, tuple s, etceteras keeps them alive.