[comp.dcom.modems] Scrolling and drawing fast on a slow machine

placeway@bbn.com (Paul Placeway) (06/24/91)

Since there is so much fuss and bother about if an original PC will
keep up at 19.2, just in case anyone out there is writing terminal
emulators, I figured I'd relate a couple of (fairly well known) tricks
to deal with hardware that is extra-slow compare to the speed of the
incoming characters.

One trick is to dump characters on the screen in as big a chunk as
possible (and still look OK).  The basic idea is to keep buffering up
characters until you have to flush, and then draw them all at once.
Just simply flushing at the end of a line, when there are no more
characters to process, or some time limit has gone by works quite
well.  This is an especially good thing to do on graphic-ish things
like X or a Mac, and is why Macintosh Kermit was the fastest Mac
terminal emulator for about 4 years.

The second important trick is the jump-scroll hack, as done by xterm
or (Suntools) shelltool.  This is an extension of the above, where the
idea is to save up whole lines and flush them only when you either run
out of input, would be scrolling the entire screen length, are about
to change the scrolling region or clear the screen or some such, or
some time period passes.  Then you scroll up N lines all at once (with
a single bitblt, block move, or something), and draw the N lines you
have saved up.  The only really hard part to getting this right is
trading off the savings of not scrolling every line with the maximum
jumpiness that the user will put up with.  (Making the maximum scroll
amount user-adjustable may be a good idea).

After using these techniques on machines that draw much slower, I
should think that a terminal emulator should have no problem keeping
up with 9600 on an original PC, and should probably be capable of
19.2.

		--P