sam@neoucom.UUCP (Scott A. Mason) (07/11/89)
Question:
Which would be faster when drawing multiple characters to a window?
1) repeated calls to DrawChar
2) building a string and calling DrawString.
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.
While I'm at it, how does Mackermit achieve such speedy screen drawing??
Thanks for the info.
--
--------------------------------------------------------------------------------
"If it ain't broke, don't fix it," and certainly don't blame me.
UUCP: {pitt,scooter,hal,cwjcc,aablue}!neoucom!sam INTERNET: sam@neoucom.UUCP
Scott A. Mason, Coordinator of Systems Operations, NEOUCOMearleh@eleazar.dartmouth.edu (Earle R. Horton) (07/11/89)
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
jmunkki@kampi.hut.fi (Juri Munkki) (07/11/89)
In article <1681@neoucom.UUCP> sam@neoucom.UUCP (Scott A. Mason) writes: >Question: > >Which would be faster when drawing multiple characters to a window? > > 1) repeated calls to DrawChar > 2) building a string and calling DrawString. > >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. The answer is that calling DrawString is several times faster than calling DrawChar (six times faster when I tested this on a Mac+). There are several reasons for this. For every call to a text drawing routine, QuickDraw and the Font Manager will have to figure out where the font is (maybe even call the resource manager to read the font from a file). Finally, when the font is ready, QuickDraw starts drawing the actual text. The text is drawn one scan-line at a time. In addition to drawing the characters, the clipping regions have to be accumulated. When you call DrawChar, the regions are created for every character. When you call DrawText or DrawString, the regions are interpreted only once. Disclaimer: This article is based on educated guesses. I might be wrong. Maybe you should get the communications manager from Apple. They should know how to write a fast terminal. This would save you the trouble of writing YATE (Yet Another Terminal Emulator). A good VT100 emulator takes about 20 pages of C source code. Add another 10-15 pages for a scrollback buffer and copy/paste support. Add another 10 pages for a decent user interface with file save and maybe a dialog to change the terminal settings. (The pages are in Courier-7 and about 25% of the lines are comments.) _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ | Juri Munkki jmunkki@hut.fi jmunkki@fingate.bitnet I Want Ne | | Helsinki University of Technology Computing Centre My Own XT | ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
amanda@intercon.uu.net (Amanda Walker) (07/12/89)
In article <1681@neoucom.UUCP>, sam@neoucom.UUCP (Scott A. Mason) writes: > 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. > > While I'm at it, how does Mackermit achieve such speedy screen drawing?? Building a string and drawing it with DrawString (or DrawText) is *much* faster. This is what MacKermit does. This is one case where your initial intuition about which would be faster is wrong. As it turns out, DrawChar is done by drawing a string of 1 character... One of the reasons for the speedup is that the font information is retrieved once per string, so the fewer times this is done, the faster the text shows up. -- Amanda Walker InterCon Systems Corporation -- amanda@intercon.uu.net | ...!uunet!intercon!amanda
pem@cadnetix.COM (Paul Meyer) (07/12/89)
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. Not only intuitively, but according to IM. In the Quickdraw chapter, it specifically states that calling DrawString is faster than calling DrawChar a bunch of times. (I can't give the page #, my Mac books are at home, but I happened to be reading this the other day.) Paul Meyer pem@cadnetix.COM Daisy/Cadnetix Inc. {uunet,boulder}!cadnetix!pem 5775 Flatirons Pkwy. GEnie P.MEYER Boulder, CO 80301 (303)444-8075x277
maxie@apple.com (Keith G. Nemitz) (07/13/89)
Another method for drawing characters to the screen (and quite legal) is to predraw the the characterset into an offscreen buffer and use copybits to blast their images to screen. This is what Red Ryder does. It is very fast because in the long run DrawString and DrawChar both call copybits eventually. If your character set is a mono-spaced font you can use the byte itself as an index into the offscreen bitmap. keith My hardware on Apple hardware, software flowing. A9F4
jmunkki@kampi.hut.fi (Juri Munkki) (07/22/89)
In article <2803@internal.Apple.COM> maxie@apple.com (Keith G. Nemitz) writes: >Another method for drawing characters to the screen (and quite legal) >is to predraw the the characterset into an offscreen buffer and use >copybits to blast their images to screen. This is what Red Ryder >does. Yuk. I have never (ever) heard anyone calling Red Ryder fast. To make this method really effective would require you to keep your whole terminal screen in an offscreen bitmap. >It is very fast because in the long run DrawString and DrawChar both >call copybits eventually. If your character set is a mono-spaced font >you can use the byte itself as an index into the offscreen bitmap. I think DrawString & DrawChar never call CopyBits. They might call something similar, but I think they do something much smarter. It is faster to process a font a single scanline at a time. I would guess that QD draws a single scanline into offscreen RAM and then blasts it onto the screen. It can then forget that line even exists in the font bitmap and move onto the next one. This saves you some indexing/registers when compared to the approach where you write a character and then forget about it when you move onto the next. P.S. I would appreciate it if people would append informative signatures. A lot of people at apple.com are actually not working for Apple and even might not have any experience in programming Macs. _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ | Juri Munkki jmunkki@hut.fi jmunkki@fingate.bitnet I Want Ne | | Helsinki University of Technology Computing Centre My Own XT | ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
amanda@intercon.uu.net (Amanda Walker) (07/25/89)
In article <2803@internal.Apple.COM>, maxie@apple.com (Keith G. Nemitz) writes: > Another method for drawing characters to the screen (and quite legal) is > to predraw the > the characterset into an offscreen buffer and use copybits to blast their > images to screen. I tried this once. I timed it, and on anything below a II, DrawText (or actually, StdText...) was *faster* than CopyBitsing each character. The only way I got any faster was to stuff things into screenBits, which is a major no-no. Even so, on a full screen of text on a Plus, I was a whole half a clock tick faster. I decided it wasn't worth it... For terminal emulators, anyway, you get much bigger wins by working on the emulator and serial port buffering code. I suspect that one reason that people like to claim that using the ROM to draw character is "too slow" is so that they can claim that their program's lack of performance is someone else's fault... -- Amanda Walker InterCon Systems Corporation -- amanda@intercon.uu.net | ...!uunet!intercon!amanda