Just a (kind of peripheral) comment:

hedrick@dartagnan.rutgers.edu (Charles Hedrick) writes:
| The performance change is an option "noScroll", for both emacs and
| xterm (resource name noScroll, command line option -ns).  It doesn't
| really prevent scrolling, as visible to the user.  It simply causes
| scrolling to be simulated by redisplaying the screen, rather than
| asking the X server to move the area up in display memory.  On many
| displays, it's faster to redisplay than to shift.  With a simple frame
| buffer, you can see why: shifting requires reading the data over the
| bus into memory and sending it back out.  Redisplaying requires only
| sending it out.  The old code is optimized for Suns and similar
| systems, where there is special hardware to move things around in
| display memory.  (This suggests a possible X server optimization: if

FYI, in case anyone gets around to implementing plain ol' stupid
16-color VGA, those ``classic'' [EV]GA modes have a latch-and-drop
mode such that an 8-bit read/write pair by the processor copies
graphics data 8 bits wide by 4 deep;  so a screen-to-screen copy is
much (read: 4x) faster than downloading image data.  Not up there with
a coprocessor ``just go blit this area'' command-queue, of course.

[and, even farther off the topic,]
If the stoopid-VGA implementation takes *so* long (not a flame, just a
realization of how busy people get) that my machine and I free up in
time, I may offer to wade in and help, as it'd be a useful thing for
me on my laptop.  The only problem is that this might not be of the
greatest good for the Linux community, as I did similar work for the
oh-so-litigious (now-)USL a few years back.  Bleah.

-Jeff Moore (jbm@sbi.com)

* disclaimers, epigrams, rock lyrics go here *