[SDL] Page flipping, double and triple buffering

[Stephane Marchesin]

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
>SDL_Flip(),
>
Yes.

> which waits for VSYNC and swaps the visible surface with the
>invisible surface.
>
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
>buffering.
>
This is not exactly triple buffering. Triple buffering in the "standard" 
understanding is when you have 3 pages in video memory. This is what 
Doom does.
In this scheme OTOH you have two pages in video memory and one page in 
system memory.
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).

Stephane