In the past it’s been said many times that glReadPixels and glDrawPixels are very slow. Apparently this is because it’s hard to optimize in drivers, and is used very little anyways.
What about glCopyPixels? It’s supposed to be a direct copy from framebuffer to framebuffer, with no jumps to system memory or anything. Would this be faster? Is it optimized in any drivers?
I was wondering because I had an idea for implementing motion blur in an application by copying the front buffer into the back buffer using alpha blending after the scene has been drawn. This avoids using the accumulation buffer, so it would not be forced into software (I hope). Would this run at an acceptable speed, or would copying to texture and drawing a quad over the scene be better?
Well, both of them have issues, actually; you’re making assumptions about the content of the back buffer after a swap, which is not (in general) safe. Depending on a number of circumstances, you may get either blitting or flipping. In addition, there’s nothing to say that it has to be blitting or flipping; if a driver decided to, oh, magically fill the back buffer with random noise after a swap, there’s nothing in the spec to prevent that.
I object to the classification of ReadPixels and DrawPixels as “very slow”. However, it is safe to say that CopyPixels, in general, is faster than either one.
Zeno: The difference is that simply redrawing the scene without clearing means you have to have absolutely no overdraw, or else the scene will be messed. Not to mention, I wouldn’t be able to use alpha blending, and I would have double the geometry stress for even a simple motion blur effect. By copying the last frame of animation into the current one, I don’t have to worry about drawing the scene twice, and the motion blur effect will probably look better as well.
Matt: I don’t see how copying the front buffer into the back after I have finished drawing into the back buffer is making an assumption about its contents. Can you clarify?
And about ReadPixels and DrawPixels being “very slow,” what I meant was that they are slow enough that I wouldn’t consider using them in a game or something like that.
Don’t know about performance, but I think it won’t look too nice, because the first frame in a game could very easily effect a frame 100 frames later. (This might be a cool effect in some cases, but would make it all blury most of the time)
HFAFiend: It would be pretty easy to change the amount of time that the motion blur would be noticable. If each frame is blended 50% with the last, a frame’s contribution to the final image will be unnoticable after 8 frames, due to limited precision in the frame buffer. Even if 75% of the last frame is used, and only 25% of the current frame, the motion blur effect will only cover about 15 frames or so.