Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu!gillies
From: gillies@p.cs.uiuc.edu
Newsgroups: comp.sys.mac.programmer
Subject: Re: QuickDraw performance boosting
Message-ID: <104700084@p.cs.uiuc.edu>
Date: 21 Feb 90 01:39:45 GMT
References: <368@usna.MIL>
Lines: 24
Nf-ID: #R:usna.MIL:368:p.cs.uiuc.edu:104700084:000:1193
Nf-From: p.cs.uiuc.edu!gillies    Feb 19 17:09:00 1990


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.