🚀 go-pugleaf

I'm in the process of writing a program that demonstrates the propagation
of the plague through Europe.  This program does *heavy* computing, and I
have been making some fairly sophisticated time/space trading to get
reasonable performance.  I now find that the program is spending more than
half of its time doing screen updating, which seems quite high ...

Each update uses FillRect to draw lots of 8x8 patterns, it occurred to me
that I might be getting clobbered by bit alignment problems.  This suggests
the following solution: I draw into an offscreen buffer, where I can guarantee
that the 8x8 patterns are being drawn with proper bit alignment, and then
BitBlt the buffer onto the screen.   The hope is that handling any alignment
difficulties only once per update justifies what amounts to drawing each
window twice.  For the offscreen buffer, I could write my own special purpose
FillRect, which could take advantage of known, favorable alignments, fixed
sizes, etc.

Question #1: Is this general approach sensible?  For the sake of
  calibration, a single redisplay involves about 1200 calls to FillRect.
  I'd like to cut redisplay time down to 200 milliseconds or less.
  Right now, redisplay requires about 600 milliseconds.

Assuming the design idea makes sense, my next problem is how to do the
BitBlt'ing efficiently.  (Even if this idea doesn't improve performance,
I might still want to use it, as it permits a very clean separation of the
"drawing" and the "updating" code.)  Presumably, CopyBits is the right
procedure, although I don't require all of its functionality (I don't
require rescaling).  Unfortunately, I haven't had much luck getting CopyBits
to do what I want.

Question #2: Can anyone point me to some publically accessible code that
  uses CopyBits to move a bit image from an offscreen to an onscreen bitmap,
  or perhaps indicate a more efficient (but Mac-appropriate) way to BitBlt?

Thanks,

Stu

stuart@gargoyle.uchicago.CSnet
stuart@gargoyle.uchicago.edu.arpa
...!ihnp4!gargoyle!stuart