Xref: utzoo comp.sys.mac:34552 comp.sys.mac.programmer:7474
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!tut.cis.ohio-state.edu!purdue!bu-cs!dartvax!eleazar.dartmouth.edu!earleh
From: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Newsgroups: comp.sys.mac,comp.sys.mac.programmer
Subject: Re: Quickdraw efficiency question
Message-ID: <14332@dartvax.Dartmouth.EDU>
Date: 11 Jul 89 04:52:57 GMT
References: <1681@neoucom.UUCP>
Sender: news@dartvax.Dartmouth.EDU
Reply-To: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Followup-To: comp.sys.mac
Organization: Thayer School of Engineering
Lines: 27

In article <1681@neoucom.UUCP> sam@neoucom.UUCP (Scott A. Mason) writes:
>Question:
>
>Which would be faster when drawing multiple characters to a window?
...
>Intuitively, I would think that DrawString would be faster, but then again,
>doesn't DrawString make repeated calls to DrawChar?  BTW, I want to do this
>for a terminal emulation program, and want maximum screen drawing speed.

     StdText works for me.  DrawString, DrawChar, and DrawText all
call StdText, so if you call StdText directly, then you save a layer
of procedure calls.  You could also make the grafProcs field of your
GrafPort point to a QDProcs record, call SetStdProcs on it, and then
call the textProc directly.  I think the big savings occurs when you
call either StdText or DrawText, and thereby draw text a line at a
time, rather than a character at a time.

>While I'm at it, how does Mackermit achieve such speedy screen drawing??

     MacKermit calls DrawText.  It owes a lot of its speed to
buffering, however.  Choice of buffering algorithm can make or break a
terminal emulator, speed-wise.

Earle R. Horton

"People forget how fast you did a job, but they remember how well you
did it."  Salada Tag Lines