[SDL] Double-buffering *and* dirty rectangle lists?

[Loren Osborn]

I *AM* familiar with the technique, and was planning on suggesting it to
Sam (along with multiple back-buffers) for the 1.3 tree (as the current
goal for 1.2 --as I understand it-- is to remain API *AND* ABI
compatible).

For those of you that don't understand the issue, I will present it
briefly:

System RAM tends to be much faster than video RAM for most operations
(the primary exception is blitting between 2 buffers *BOTH* in video
RAM)...  As a result, it is often fastest to construct a composite frame
in system memory, and only update the part of the screen that changed in
the last N frames [where N = 1 + Total number of video buffers].  Even
though the whole screen is being drawn (into system memory) every frame,
only the parts that change need to be updated via the relatively slow
PCI bus. This then can be combined with traditional back-buffering
techniques, assuming that you keep a dirty-rect list for each back
buffer.  It can be argued that it might be SDL's job to hide this from
the user when the user uses a software surface, and SDL_UpdateRects(),
but that's what group debate is for... right?

I will save discussing the merits of multiple back-buffers for another
email... (FYI, I see almost no reason to have more than 2 back-buffers)

As far as doing this with SDL in its current state, I think it *SHOULD*
work for a *REAL* hardware double-buffered surface (I would ask Sam his
opinion)... but I doubt it will work correctly when SDL is emulating
hardware double-buffering.  I have not tested this myself, so YMMV.

Best of luck,

-Loren

On Fri, 2002-08-23 at 17:52, Matthew Bloch wrote:
> Has anyone tried doing animation in SDL with both techniques, or is this a 
> disaster waiting to happen?  I'm trying to maximise animation speed for 
> potentially very slow machines (albeit ones with 8MB graphics cards) so what 
> I'd like to do is use a double-buffered hardware display surface, and also 
> keep lists of dirty rectangles for each buffer, so I can avoid a whole-screen 
> redraw each frame.  The dirty list is a bit more complicated as a result, I'd 
> imagine, but otherwise I expect it should give me a bit more speed than using 
> software buffers and SDL_Updating (to get a smooth single-buffered display) 
> or doing full-screen redraws.  Any thoughts on this?
> 
> cheers,
>