bwb@andante.UUCP (Bruce Ballard) (07/20/89)
I'm reading Knaster's Macintosh Programming Secrets for the
first time, and I wonder whether the computation of rowBytes
on pages 202 and 216 is known to be incorrect, or whether I am
missing something.
For a bitmap (p. 202) he gives
(((Right - Left - 1) div 16) + 1) * 2
which is equivalent to the simpler formula
((Right - Left + 15) div 16) * 2
but either is correct. For a pixmap (p. 216), however, he gives
((depth*(Right - Left - 1) div 16) + 1) * 2
which he then uses to compute 208 as the rowBytes for an 8-bit-deep
pixmap having 200 pixels across. But at this depth, we want one byte
per pixel, right, so we should have a rowBytes of 200?
It seems that a *correct* formula, which is easily derived from
the alternate one I gave above, is
(depth * (Right - Left + 15) div 16) * 2
The difference is significant: for his 200-by-200 pixmap, 1600 of
his 41600 bytes are wasted.
I love the book, but can someone clarify this point?
-Bruce Ballard
bwb@allegra.att.comMAC.ROMOS@applelink.apple.com (Ian Hendry) (07/21/89)
In article <21104@andante.UUCP> bwb@andante.UUCP (Bruce Ballard) writes: > (depth * (Right - Left + 15) div 16) * 2 If you are using Color QuickDraw, then I *believe* you should be using a long word aligned width (rather than a word aligned width). I am 99% sure that ColorQD can go *much* faster if rowBytes is long aligned. The formula should read something like this: rowBytes := (depth * (Right - Left + 31) div 32) * 4; or for the C buffs: rowBytes = (depth * (Right - Left + 31) >> 5) << 2; Ian Hendry MAC.ROMOS@applelink.apple.com Make sure my name is in the subject of any Email, or post replies to network. TE: 408-974-4737 Disclaimer: It was all HIS idea anyway! Nothing I say reflects anything my employer means... or anything I mean for that matter.