🚀 go-pugleaf

In article <8419DMB@PSUVMA> DMB@PSUVMA.BITNET writes:
>
>  About scrolling and updating fast:
>
[ommitted article; the basic idea was to draw into an offscreen bitmap and
use Copybits to put the bitmap on the screen]


I have 1 optimization to add to this approach.  That is the fact that
CopyBits is fastest when the source and destination bitmaps are aligned on
the same bit boundary.  If this is not true, then Quickdraw will have to
shift each row of the bitmap as it copies it.

The trick to use in this case is to do the shifting off screen so that the
user doesn't see it.  This means doing an extra Copybits offscreen just to
perform the alignment.  Even though this takes some time, the visual effect
is much better.

Now for the theory.

The purpose of the ScrollRect calls is to conserve bits on the screen.  In
most applications, drawing the window is time-consuming because it involves
converting various shapes, text, etc. into a bitmap.  Because of this, you
want to reuse as many of those bits as possible.  That is exactly what
ScrollRect does.

If your application already has converted the image into a bitmap, then
there is no need to use ScrollRect.  You can just use Copybits to transfer
the bits to the proper place.  Copybits (if you do the alignment mentioned
above) is fast enough to do the copy.  MacPaint is a perfect example, since
it has the entire bitmap stored internally.

For an arbitrary application, drawing to an offscreen buffer will be useful
only if the bits can be reused, since drawing the offscreen bitmap takes as
long as drawing to the screen.  You can however, use the offscreen bitmap as
a cache and refresh the screen from it when possible.  (For example, when a
dialog comes up.)

-- 
Larry Rosenstein

Object Specialist
Apple Computer

AppleLink: Rosenstein1
UUCP:  {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: lsr@Apple.CSNET