Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!indri!paz.geology.wisc.edu!jct
From: jct@geology.wisc.edu (John C. Terranova)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Wide offscreen bitmap won't receive draw commands
Summary: I dare you to try using a bitmap with rwoBytes >= 8K
Message-ID: <1989Aug19.221033.2241@geology.wisc.edu>
Date: 19 Aug 89 22:10:33 GMT
References: <22321@andante.UUCP>
Reply-To: jct@paz.UUCP (John C. Terranova)
Organization: UW-Madison Dept of Geology & Geophysics, Madison WI
Lines: 29

In article <22321@andante.UUCP> bwb@andante.UUCP (Bruce Ballard) writes:
>I've been using offscreen bitmaps for some time but now I need one
>that's 1728 bits wide (for an 8-1/2' image at 300-dpi) and it nothing

I can't explain your problem, but I just solved a similar problem of
my own.  I maintain an 8 bit deep pix map.  The dimensions of the
pix map are dependent of the input file.

The data file I used for most of my testing was 793 across by 203 down
at one pixel per matrix element.  No problem with this file.  But when
a new file was 8947x40....

No crashes but total and complete garbage when I CopyBits to the screen.
It turns out that even though rowBytes (in the BitMap/PixMap structure)
is a 16 bit integer, the high order 3 bits are reserved.  When rowBytes
is >= 8K bit 13 is turned on but Color QuickDraw steps on this bit
somewhere.  IM-V p52 has a picture of this.

Looks to me like it is time for rowBytes to be a 32 bit LongInt.

>-Bruce Ballard

+----------------------------------------------------------------------------+
|  John Terranova  <-- me          disclaimer -->  What the hell do I know?  |
|     jct@ice.geology.wisc.edu  <-- address         I come from Waunakee!    |
+----------------------------------------------------------------------------+
song lyric: We'll drive into the sun and maybe never comin' back.
            We're goin' cruisin'. Do you want to come?  Cruisin'.
            Do you want to come along with me?    -- Gerard, Cruisin'