First I want to say thank you all for your timely replies. This is all good food for thought. I've been programming more many years, but fast graphics rendering is new territory for me.
I'm hoping to fine something like a buffer_blit, where I can set all the pixels to change using basic operators, blit them all at once to a pixel buffer, then swap the visible buffer. Ideally it will only change the region of the pixel buffer that needs changing. Because I want layers, I would like to take advantage wherever possible of the available hardware features. I.E. ideally I am hoping that the layers can be textures in memory that get composited in hardware onto the screen. Maybe this is wishful thinking though? I'm also thinking that maybe I can reduce the number of active layers from N down to 3 - the active layer, the layers below it, and the layers above it. Obviously only the active layer needs any sort of sprite-like animations and it on this layer than response time is most important. Having to layer the top layers ontop of it may also play a factor but, as I suggested, I can merge them all together in one time and then use the merged result to layer on top of the active layer. I'm a little nervous about going the C/C++ route. It's been a few years since I used them, I'm new to Python, and jumping into coding Python extensions with C/C++ is not particularly palatable (though I'll do it if I have to.) > Any GUI toolkit will work if you find the low-level access > to their image memory buffers. That's another new step for me. Any ideas where to start? Thanks! -- http://mail.python.org/mailman/listinfo/python-list
