Ian Mallett wrote:
The only application the PyGame drawing calls have for OpenGL is drawing to textures, which can then be drawn to the screen with the OpenGL drawing calls.
surface directly into the framebuffer. For one-off blitting, this
is somewhat simpler than using a texture and probably just as
fast.
It will be faster than making a new texture and then drawing that. However, if you create a texture, and then simply update it, it will definitely be faster (especially since, you probably don't need to update every pixel, you can use glTexSubImage so you needn't copy over everything each time you draw).
If you want to get fancy, you can use a pixel buffer object to do asynchronous data transfer over the graphics bus. This is the fastest way to do it, but it's much more complicated.
Faster than all of these is just to draw something with OpenGL itself. In addition to eliminating SDL's overhead, you don't need to deal with messy stuff: with glDrawPixels, there are still tests that run (if I recall, the pixels have to get packed and then unpacked by the driver, which takes time); with textures, you need a texture tap, which is the slowest operation* fixed function GPUs can do. Plus, GPUs are optimized for drawing stuff--and even if they weren't, it's inherently a parallel problem, so of course the GPU will be better at it.
Ian
*Cache coherency is a harsh mistress.