pjw@usna.MIL (Prof. Peter Welcher) (02/18/90)
I've got a program where my chief performance problem is writing to the screen. (Any others are pure coding problems.) It seems like QuickDraw bottleneck procedures are aptly named. Various people have suggested using off-screen bitmaps. Benchmarking seems to refute the theory that this produces faster results: you have the drawing cost *plus* the CopyBits cost. Am I missing something ? I'd appreciate it if anyone could share folk-wisdom on fast screen drawing (lines & text). I don't need gory details, just a sketch or a fresh idea. The program involves a spreadsheet-like display. I've found that drawing lines around cells is much worse than drawing a grid, presumably because many more lines are being clipped. There are other, fairly obvvious, improvements I've been able to make. What I'm looking for is things like off-screen bitmaps: whole approaches to fast drawing that I might not have thought of. Tricks of the trade, etc. Since I read the news groups irregularly, and mayy lose a reply in the clutter, I'd appreciate email responses: pjw@sma.usna.navy.mil Thanks !
gillies@p.cs.uiuc.edu (02/21/90)
What sort of performance do you need? In what color mode? Have you calculated the throughput (bytes/pixels/second) your application requires? This type of calculation might help you to decide whether to use quickdraw, pure C code, or hand-optimized assembly code. For instance, it is evident that MS-Word is designed to scroll color quickly in 8-bit mode. Just look at the windows it creates -- one single word (4 dots) from the left-hand side of the screen, in 8-bit color mode, and aligned similarly on the right hand side. This simplifies vertical byteBLT's. Furthermore, MS-Word bypasses quickdraw as long as the entire window is visible. If you move a window partly off-screen, MS-word goes through quickdraw and slows down tremendously. If your scrolling is too slow, then perhaps you're not being clever during your redraw. You are using ScrollRect, aren't you? If so, consider custom code (a la MS-Word). For every scroll, your application should be able to quickly decide exactly what needs to be refreshed, based on the invalid regions, and draw nothing else. Also, it might help if your application would scroll in 1-cell units, rather than some other unit of measure.