Re: [MiNT] NetSurf menu redraw / was: Menu redraw

[Jo Even Skarstein <joska@online.no>]

On Sun, 2013-04-14 at 07:43 +0200, Peter Persson wrote:

> Basically (screen is supposed to be locked when you're doing this):
> 1. WF_FIRSTXYWH
> 2. response equals dirty are? Go to 4.
> 3a. redraw by following rectangle list (since there are obviously more
> entries)

This is not obvious at all. There could perfectly well be just one
rectangle in the rectangle list even if the first rectangle is different
from the dirty rectangle. The only case where the dirty rectangle and
the first rectangle in the list is identical is when an area completely
within the window's work area is uncovered (e.g. by closing a dialog or
a window).

> 3b. redraw without using rectangle list (since there are no more
> entries anyway)

I don't think this optimisation can be measured. Yes, you save one call
to wind_get(), but at the cost of comparing two rectangles and also
complicating the code a bit.

Normally you would do something like...

GRECT r;

wind_get(handle, WF_FIRSTXYWH, &r.x, &r.y, &r.w, &r.h);
while (r.w && r.h)
{
	if (intersect(dirty, &r))
	{
		redraw(r);
	}

	wind_get(handle, WF_NEXTXYWH, &r.x, &r.y, &r.w, &r.h);
}

Now, if the dirty rectangle and the first rectangle is identical, the
while-loop will break after the second call to wind_get. No further
checks necessary, no special cases. But as you say, you can avoid the
cost of the intersect-check and the second wind_get by comparing the two
rectangles:

wind_get(handle, WF_FIRSTXYWH, &r.x, &r.y, &r.w, &r.h);

if (dirty.x == r.x && dirty.y == r.y && dirty.w == r.w && dirty.h ==
r.h)
{
	redraw(dirty);
}
else
	while (r.w && r.h)
	{
		if (intersect(dirty, &r))
		{
			redraw(r);
		}

		wind_get(handle, WF_NEXTXYWH, &r.x, &r.y, &r.w, &r.h);
	}

It's probably a tiny bit faster, but not in real life because it only
affects single redraws like closing a dialog that's completely within
the window's work area. It has no effect in situations like dragging a
window across another window.

It doesn't do any harm either, but I prefer the code without this
optimisation. Simple is usually better.

Jo Even