Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!know!cs.utexas.edu!natinst!balkan!crucible!al
From: al@crucible.UUCP (Al Evans)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Can the Mac actually do animation?
Summary: You're looking at it wrong
Message-ID: <314@crucible.UUCP>
Date: 4 Apr 91 16:05:00 GMT
References: <6205@cactus.org> <2966@cod.NOSC.MIL>
Reply-To: al@crucible.UUCP (Al Evans)
Followup-To: comp.sys.mac.programmer
Distribution: usa
Organization: PowerTools, Austin, TX
Lines: 26

In article <2966@cod.NOSC.MIL> page@cod.NOSC.MIL (Ward C. Page) writes:

>I'm getting about 100Hz update on the simple symbology that I'm moving
>around the screen.  The problem is not with the update rate but with the 
>flicker caused by rewriting the screen a couple times per frame.  If you
>can't draw during the retrace then your not really doing animation.  Your
>just flailing away at the screen.  Control of the update rate is 
>important in animation, and it's done by syncing with the screen refresh
>somehow.  Normally, this is done with a double buffered system.

Sorry, Ward, but you're simply looking at it wrong. Vertical blanking is
completely irrelevant to Mac animation when it's done properly. In this
context, "properly" means "using offscreen bitmaps." The process is fairly
simple: 1) construct the relevent area of background in an offscreen
bitmap, including the part that lies under the current screen image;
2) draw the new image into this bitmap; 3) Copybits the bitmap to the
screen at a time of your choosing, erasing the old image and drawing the
new one simultaneously. No flicker. Naturally, the procedure gets a bit
more elaborate if animated images can overlap, but the approach remains
the same.
					--Al Evans--
-- 

Al Evans                                                Reality is like this:
al@crucible.uucp                                          We are born knowing
uunet!execu!sequoia!crucible!al                 the world isn't what we think.