Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim From: tim@hoptoad.uucp (Tim Maroney) Newsgroups: comp.sys.mac.programmer Subject: Re: Quickdraw efficiency question Message-ID: <7943@hoptoad.uucp> Date: 11 Jul 89 04:45:18 GMT References: <1681@neoucom.UUCP> Reply-To: tim@hoptoad.UUCP (Tim Maroney) Organization: Eclectic Software, San Francisco Lines: 34 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. DrawString. Smaller trap overhead, fewer internal calls to the Font Manager, some built-in heuristics to speed things up. DrawText is even better,m supposedly. >While I'm at it, how does Mackermit achieve such speedy screen drawing?? I don't know for sure, but a lot of terminal emulators use a reprehensible technique sometimes called "bit-blasting". This involves bypassing both Quickdraw and the Font manager and copying the bits of characters directly into the screen. It *is* fast, but there are serious portability problems. Drawing straight into the screen bitmap is a major no-no these days, and of course when fonts change in System 7.0, there is a good chance many of these programs will break. You also have to figure your own clipping and visible regions usage, no easy task to do correctly. The early generation of bit-blasters were mostly incompatible with MultiFinder, and the new generation will probably be incopmpatible with some add-on screens and with System 7.0. Caveat implementor, in Kari Dubbelman's clever phrase.... -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com Postal: 424 Tehama, SF CA 94103; Phone: (415) 495-2934 "When errors are found in old research, the relevant theories are re-examined. When facts contradict theory, theory gets dumped. Is that why the NLP people are unwilling to research their facts?" -- Jerry Hollombe on sci.psychology