Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!apple!parent
From: parent@Apple.COM (Sean Parent)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Text Drawing at speeds greater than 1200baud
Summary: Blasting Directly to the Screen
Message-ID: <25017@apple.Apple.COM>
Date: 30 Jan 89 19:41:03 GMT
References: <1728@helios.ee.lbl.gov> <2534@pegasus.ATT.COM>
Organization: Apple Computer Inc., Cupertino, CA
Lines: 27

In article <2534@pegasus.ATT.COM>, ech@pegasus.ATT.COM (Edward C Horvath) writes:
> In article <24307@apple.Apple.COM> parent@Apple.COM (Sean Parent) writes:
> >There is no way to tell for sure that there are not any windows in front of
> >your window. The system owns the screen.
> 
> From article <1728@helios.ee.lbl.gov>, by beard@ux1.lbl.gov (Patrick C Beard):
> > Not true.  It is very easy.  Just look at the visRgn of the window in
> > question.  Clip your optimized drawing directly to the screen to this and
> > you won't get in trouble.  I know, I've done it.  It is dirty pool, but
> > it does work.
> 
> There is NOTHING "dirty pool" about this technique: the visRgn is, quite
> precisely, the visible region of your port, and IM-I (Quickdraw) makes it
> very clear that your drawing will be clipped to the visRgn (among other
> things).  Limiting drawing to the visRgn is a perfectly wonderful (and
> safe, presumably forever) means of limiting the cost of updates.

The point that I was making has been lost. Of course you can use the VisRgn to
optimize your update code. Just don't update the screen with MOVEs to screen
memory. Use QD (CopyBits is very fast).

Also, to quote Inside Mac Vol 1. "The visRgn field is manipulated by the Window
Manager...The visRgn has no effect on images that aren't displayed on the
screen." So don't use it in your printing code and keep in mind that it is the
visable area of a port that is owned by a window.

Sean