On Sat, 14 Dec 2002, Andreas Beck wrote:
> I spent quite a while thinking this code through, and suppose I got it
> right. I am not quite sure about the last two ifs in each chain. I think one
> could use greater/less-or-equal in the comparisions as well, thus correctly
> handling regions that just touch the borders.
/me hangs his head
Shame on me for being a cut-and-paste monkey and not revisiting that code.
All the changes look fine to me. Thanks a bunch!
BTW, on my TODO list is a helper library that does dirty-region tracking,
but it is something I probably won't get to for a long while. There
are other targets that could use dirty region management (e.g. tile).
If this sounds like an interesting diversion for anyone they are
welcome to take it off my hands :-). It is quite a fun challenge
for those of us who enjoyed algorithms 101.
The API would be something like this:
/* Initialize a helper instance and return a handle to it. */
dirty_handle = dirtyhelper_init(max_regions, cost_per_blit, cost_per_pixel,
do_blit_function_pointer, max_budget);
max_regions: A user-definiable cap on the number of dirty-regions tracked
cost_per_blit: How many points does sending a blit command cost, not including
the cost of the pixel data payload.
cost_per_pixel: How many points should be calculated per pixel when figuring
out the cost of sending the pixel data payload.
do_blit_function_pointer: A pointer to a function that unconditionally
blits a region from the backbuffer to the front-buffer.
max_budget: A limit on the number of points the dirty region manager
is allowed to accumulate.
dirtyhelper_exit(&handle) /* Frees the instance and destroys the handle */
/* Mark a region dirty, but don't blit any regions. This means even if
it is horribly inefficient to do so, when the function returns all
the dirty data should be contained in <= max_regions rectangles. */
void dirtyhelper_dirty(handle, x, y, w, h);
/* The manager adds the allowance to it's accumulated point budget. Then,
it has the option of blitting some data to the screen in order to
more efficiently fit the new region into its rectangles. The
manager must subtract the cost of that blit from it's total bugdet,
which must remain above 0.
*/
void dirtyhelper_dirty_blit(handle, x, y, w, h, allowance);
/* These are the same, for marking a region clean, e.g. when an accelarated
solid-fill primitive overwrites dirty pixels before they were moved to the
front-buffer. */
void dirtyhelper_clean(handle, x, y, w, h);
void dirtyhelper_clean_blit(handle, x, y, w, h, allowance);
/* Just let the dirty-region manager do some internal reorganization
and blitting, without making anything new dirty or clean. */
void dirtyhelper_blit_some(handle, allowance);
/* Flush all dirty regions. */
void dirtyhelper_blit_all(handle);
/* Explicitly set the number of points the dirty-region manager has
available to spend. */
void dirtyhelper_budget(handle, budget);
Targets would have the option of using
dirtyhelper_blit_some/dirtyhelper_{clean|dirty}_blit or just
using dirtyhelper_blit_all depending on their requirements.
Network based targets might also appreciate the ability to tune the
costs at runtime to adjust for dynamic latency/bandwidth ratios.
--
Brian
P.S. It boggles my mind that any of the X targets actually work
in a threaded environment :-)
