Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!mcvax!kth!draken!tut!santra!kampi!jmunkki
From: jmunkki@kampi.hut.fi (Juri Munkki)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Help: Using CopyBits for Update
Message-ID: <21965@santra.UUCP>
Date: 13 May 89 21:40:28 GMT
References: <1617@neoucom.UUCP> <KSITZE.89May10081130@san_juan.nmsu.edu> <7254@hoptoad.uucp> <21931@santra.UUCP> <1203@speedy.mcnc.org> <7287@hoptoad.uucp>
Sender: news@santra.UUCP
Reply-To: jmunkki@kampi.hut.fi (Juri Munkki)
Organization: Helsinki University of Technology, Finland
Lines: 54

In article <7287@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>In article <1203@speedy.mcnc.org> kk@mcnc.org.UUCP (Krzysztof Kozminski) writes:
>>How about this: sometimes the visible and/or clipping regions on the
>>screen are not rectangular => drawing to the screen is slower than
>>drawing to an offscreen *rectangular* PixMap due to the extra effort
>>necessary for the proper clipping of each object drawn.
>
>I'm pretty sure the opposite is true.  If part of your window is
>covered, then the reduced Font Manager overhead from not drawing the
>clipped-out characters makes drawing much faster.  Clipping resolution
>seems to be more than fast enough to make this a win.  I have observed
>this empirically with TOPS Terminal.  However, with an offscreen
>bitmap, every character must be drawn.

According to IM-I the whole string is drawn into an offscreen buffer
and only clipped after that. A complex clipping region will slow
down the copybits from this buffer to the screen. I still think you
don't loose any significant time. (Especially if you keep the screen
and your own offscreen bitmap aligned.)


From IM-I 172:
[	Warning: QuickDraw temporarily stores on the stack all of the text you
	ask it to draw, even if the text will be clipped. When drawing large
	font sizes or complex style variations, it's best to draw only what
	will be visible on the screen. You can determine how many characters
	will actually fit on the screen by calling the StringWidth function
	before calling DrawString.
]

None of this will be relevant if you use DrawChar for every character you
draw. (Why this is not a good idea was discussed a few months ago.)

It's somewhat easier to implement scrolling (or insert/delete) functions
if you keep an offscreen bitmap. Imagine that you have the calculator DA
in front of your terminal window. You update region after the operation
will most probably not be a rectangle. To update, you have to call DrawString
several times. QuickDraw will have to regenerate the mask from the region
every time you call DrawText. It only has to generate the mask once, when
you call copybits.

For operation as the front window, you probably have a small speed advantage
if you don't use the offscreen bitmap. My reason for using the offscreen
bitmap was that updating the screen was a lot faster & easier. Now that the
VT100 is ready, I find that it wouldn't take too much work to remove the
offscreen bitmap. I might have to do this, if I start writing YATI (Yet
Another Telnet Implementation). Right now (with only one offscreen buffer)
I don't think it's worth changing the program. Even with the bitmap, I
can run the program in a 160KB multifinder partition.

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