optimizing redrawing

[nelson-gtk crynwr com]

Owen Taylor writes:
 > "Daniel J. Kressin" <kressd11@sol.acs.uwosh.edu> writes:
 > > Thanks.  It's better than before, but still not as responsive as it maybe
 > > could be.  If any one else has other suggestions, I'd love to hear them.
 > 
 > Turn off OpaqueResize? 
 > 
 > You could try using a short timeout - i.e. wait until there is
 > say a 100ms pause between configure events before redrawing your
 > screen.

It used to be that X servers were so slow that you couldn't do an
OpaqueMove.  Now they're fast enough that you can, because most
clients are programmed so that there isn't that much to do.
Currently, most X window managers don't attempt OpaqueResize, because
they assume that programs are so slow that it wouldn't work well.

Maybe this is the wrong way to do it?

Maybe the right way to do it is to have an adaptive algorithm, so that 
the client draws only part of its display if it gets multiple redraw
requests in the same second AND it can't keep up.  And this could be
scaled, so that as computers get faster and faster, the client would
draw more and more of its window.  And yet the code would still work
on older machines that can't do that.

The algorithm would be a little complicated -- more complicated than I
want to lay out here.  But it ought to be usable within an application
like this:

if (adaptiveredraw(&redrawhistory1)) {
	draw();
	draw();
	draw();
	if (adaptiveredraw(&redrawhistory2)) {
		draw();
		draw();
		draw();
	}
}

At *very* least, an application ought to be able to set a background
color for its drawing area.

-- 
-russ nelson <rn-sig@crynwr.com>  http://crynwr.com/~nelson
Crynwr supports Open Source(tm) Software| PGPok |   Freedom is the primary
521 Pleasant Valley Rd. | +1 315 268 1925 voice |   cause of Peace, Love,
Potsdam, NY 13676-3213  | +1 315 268 9201 FAX   |   Truth and Justice.