[SDL] Dirty Rects and Sprig

[Clemens Kirchgatterer]

Jonathan Dearborn <grimfang4 at hotmail.com> wrote:

> I'm considering implementing a toggleable dirty rect collection in
> Sprig's primitives. When enabled, the rect that encloses each drawn
> line, circle, etc. would be added to some sort of stack or array. The
> array would be accessible to the programmer so his/her own dirty
> rects could be added to it. Then at the end of each frame, a Sprig
> function would be (optionally) called to combine rects appropriately.
> Then either you call SDL_UpdateRects or maybe that rect combining
> function could do it for you. I'm thinking that there should be
> different levels of optimization so that you can choose the level
> that works fastest for your application. You might even test the
> results to get runtime adjustment to the most efficient level.
> 
> Those a bunch of statements, so here are some questions:
> 
> Is this a good idea?

for a software renderer, dirty rect optimization is often a big win.

> Any good reasons out there for choosing a stack, an array, or a
> linked list?

go for the latter.

> Is there anything I can do about single pixels, or do I
> have to wrap them in a rect?

single pixels are seldom used anyway. wrap them in a rect.

> What do you think of the optimization levels idea?

in my own render engine i have implemented different screen update
strategies, each is fast in spczific use cases:

1. immidiate update -> each blit is immidiatly updated on the screen
2. dirty rect list  -> each blit is stored in a dirty rect list and
                       the list is updated after all blits are done
3. one dirty rect   -> all dirty rects are combined to one big rect
                       and the screen is updated once with that
4. whole screen     -> first do all blits then update the whole screen

i want to do one more but i never came around to code it. a combination
of 2 and 3, where overlapping rects are combined to one bigger rect and
non overlapping rects are stored in the dirty rect list again. this
could be a really big improvment sometimes because it avoids updating
the same screen region multiple times without updating likly unchanged
regions.

best regards ...
clemens