stuart@gargoyle.UUCP (05/14/87)
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