Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!ucsd!nosc!humu!page
From: page@humu.NOSC.Mil (Ward C. Page)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Can the Mac actually do animation?
Message-ID: <552@humu.NOSC.Mil>
Date: 5 Apr 91 20:27:51 GMT
References: <6205@cactus.org> <2966@cod.NOSC.MIL> <314@crucible.UUCP>
Distribution: usa
Organization: Naval Ocean Systems Center, Kaneohe Hawaii
Lines: 30

In article <314@crucible.UUCP> al@crucible.UUCP (Al Evans) writes:
>
>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
                         ^^^^^^^^^^
This isn't quite correct.  You will reduce flicker but not eliminate it.
There are two causes of flicker: the flicker caused by seeing the erase
of the old symbology before the redraw, and the flicker caused when the
gun starts drawing the CopyBits half way through the scan, thus taking
two scan fields (frames) to get the copybits to the screen.  Without
syncing to the retrace interval you can't guarantee that you won't see
this.  The faster the updates the more you will notice this.  Double-
buffering was designed to address both these problems.  Without it, you
have to handle it by yourself.


>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.


Ward Page
Naval Ocean Systems Center
Kaneohe, Hawaii