[SDL] Page flipping, double and triple buffering
stephane.marchesin at wanadoo.fr
Thu Oct 28 13:31:59 PDT 2004
Gabriel Gambetta wrote:
>Hi guys, I'm on the usual Quest for Smooth Animation. I know this is a
>common topic but I didn't find any post that tells the whole story. So
>I'll try to do that, please let me know if I got it right.
>1) Create the video surface with SDL_DOUBLEBUFF | SDL_HWSURFACE.
Yes. Note that SDL_DOUBLEBUF automatically & silently sets
SDL_HWSURFACE, so that there's not difference between SDL_DOUBLEBUF |
SDL_HWSURFACE and SDL_DOUBLEFUF.
No idea whether this is/should be documented.
>2) If it succeeds (flags & SDL_HWSURFACE == SDL_HWSURFACE), you get a
>video memory chunk with enough space for TWO screens. The video card
>displays one of these at a time. So you draw into the offscreen one (the
>one represented by the returned SDL_Surface, right?), and call
> which waits for VSYNC and swaps the visible surface with the
You don't get vsync all the time, this is backend-dependent.
>3) Because the back buffer is on hardware, alpha blitting (which I do a
>lot) is slow because it requires read. Therefore, you also allocate a
>second surface, with the same dimensions and format of the screen, but
>as a software surface. You draw on this third buffer, copy the dirty
>parts to the hardware back buffer, and call SDL_Flip(). This is triple
This is not exactly triple buffering. Triple buffering in the "standard"
understanding is when you have 3 pages in video memory. This is what
In this scheme OTOH you have two pages in video memory and one page in
David Olofson calls this semi triple buffering, and I think the name is
quite meaningful, actually.
As for alpha blitting acceleration, well, this is backend-dependent
(heh. We should release glSDL sometime...)
>4) If 1) didn't succeed, instead you got a software surface (and the
>display memory which you can't directly touch). You draw on this
>surface, and copy the dirty bits with SDL_UpdateRect(). The copy is
>immediate, no wait for VSYNC, so you get tearing. The best you can do is
>try to have a frame rate close to the monitor's refresh rate.
Not sure this is a good idea, since you'll never be at the exact
monitor's refresh rate (not to mention you don't always know the refresh
rate...). Then, you'll get the worse tearing that is. I think you'd
better draw as fast as possible to reduce tearing (considering that it's
impossible to remove it altogether).
More information about the SDL