[SDL] Dirty Rects and Sprig
clemens at 1541.org
Sat Sep 20 06:37:31 PDT 2008
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
best regards ...
More information about the SDL