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'