Path: utzoo!attcan!uunet!mcvax!enea!kth!draken!tut!santra!kampi!jmunkki
From: jmunkki@kampi.hut.fi (Juri Munkki)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Text Drawing at speeds greater than 1200baud
Message-ID: <18791@santra.UUCP>
Date: 19 Jan 89 01:39:24 GMT
References: <2243@uokmax.UUCP> <27572@ucbvax.BERKELEY.EDU>
Sender: news@santra.UUCP
Reply-To: jmunkki@kampi.UUCP (Juri Munkki)
Organization: Helsinki University of Technology, Finland
Lines: 43

In article <27572@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes:
>The ultimate in text drawing speed can be achieved by:
>(o) using a custom font, where each character is 7 pixels high, and, say,
>9 pixels tall. f there is one pixel of white space between characters,
>then each pixel fits in an 8-bit wide cell.

You mean 7 pixels wide. Looks awful and you can only get 64 characters per
line on a 512 pixel wide window. I wouldn't want to read a font like this.

>(o) constrain motion and growing of the window, (a la hypercard) so that
>the portRect is always on a byte boundary.

No objections here. I do not restrain my windows, but the effect on speed
is visible on a MacPlus. This is because I use an offscreen bitmap to
contain my text screens. If the bitmap and the window are not exactly
aligned, QD has to do a lot of bit-shifting.  Zooming the window positions
it intelligently to a word boundary (I plan to document this feature in the
manual).

>(o) use hand-tuned assembly instructions to scroll the screen using 
>loops unrolled into lots of move.l instructions.

Movem.l should be faster...at least apple is using them. QD Copybits
is almost as fast as BlockMove, and blockmove uses movem.l. I do not
see the need to write a custom bitmap scrolling routine.

I recommend giving the serial driver a reasonable large buffer to work
with. 8KB seems to be ok, but you might make it 16KB or more, if you're
really worried about missing characters & have enough RAM. Usually text
is received in bursts.

The original question was about achieving 2400 bps. You don't need
to optimize the scrolling at these speeds. Just remember that you
usually don't need to call your update routine after the screen scrolls
up. Most terminal programs do not do update their windows even when they
really should. Try ls -R and open a desk accessory. The lines that
scroll up from under the da are not updated. At least VersaTerm and
Microphone fail this test.

_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
|     Juri Munkki jmunkki@hut.fi  jmunkki@fingate.bitnet        I Want   Ne   |
|     Helsinki University of Technology Computing Centre        My Own   XT   |
~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~