bwb@andante.UUCP (Bruce Ballard) (08/18/89)
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 send via DrawPicture or other quickdraw calls, even simple things like LineTo, extend past the screenBits.bounds. Instead I get garbage bits. This despite the fact that I've tried ClipRect after doing SetPort to the GrafPtr that's been associated via SetPortBits to the offscreen bitmap. What am I missing? I've read TN-163 and other info of offscreen drawing but I can't see where I'm going wrong? I'm using LSC 3.0 on a MacII w/ 8M. -Bruce Ballard bwb@allegra.
oster@dewey.soe.berkeley.edu (David Phillip Oster) (08/19/89)
In article <22321@andante.UUCP> bwb@andante.UUCP (Bruce Ballard) writes: >What am I missing? If you read QuickDraw in Inside Mac, vol. 1, it will tell you that when you create a new grafport, the clipRgn gets initialized to wide open, and the visRgn gets initialized to screenBits.bounds. Big off-screen grafports should probably do a: ClipRect(&thePort->portRect); RectRgn(thePort->visRgn, &thePort->portRect); before drawing on it. --- David Phillip Oster 7 line signature follows Keith Sproul, head of microcomputer support at Union Carbide, NJ, complained about the poorly digitized fellatio on an IBM porno program. "Mac is better on everything, and this is no execption." -- "Computer Porn at the Office" by Reese Erlich, _This_World_, S.F. Chronicle, p.8, Aug 13, 1989 Arpa: oster@dewey.soe.berkeley.edu Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu
jct@geology.wisc.edu (John C. Terranova) (08/20/89)
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'
keith@Apple.COM (Keith Rollin) (08/21/89)
In article <30755@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >In article <22321@andante.UUCP> bwb@andante.UUCP (Bruce Ballard) writes: >>What am I missing? > >If you read QuickDraw in Inside Mac, vol. 1, it will tell you that when >you create a new grafport, the clipRgn gets initialized to wide open, and >the visRgn gets initialized to screenBits.bounds. Big off-screen grafports >should probably do a: > ClipRect(&thePort->portRect); > RectRgn(thePort->visRgn, &thePort->portRect); >before drawing on it. Dave, I think that Bruce also read the line in Inside Mac, page I-149 that says "The visRgn has no effect on images that aren't displayed on the screen." I don't know if that warning is correct or not, or if it is what it's supposed to mean, but it looks to me that people using offscreen bitmaps should indeed pay attention to what the visRgn is set to, as you pointed out. ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions
kk@mcnc.org (Krzysztof Kozminski) (08/21/89)
In article <34168@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: >In article <30755@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >>In article <22321@andante.UUCP> bwb@andante.UUCP (Bruce Ballard) writes: >>>What am I missing? One thing not mentioned by previous posters: be sure to do EraseRect on your entire off-screen bitmap before you start drawing (lack of this may account for the garbage you saw after drawing). If I remember correctly, the code given in TN129 (or is it 126?) has no provisions for cleaning the off-screen drawing area. >>Big off-screen grafports should probably do a: >> ClipRect(&thePort->portRect); The above is probably superfluous: the drawing gets clipped to portRect anyway. >> RectRgn(thePort->visRgn, &thePort->portRect); >>before drawing on it. > >Dave, I think that Bruce also read the line in Inside Mac, page I-149 that >says "The visRgn has no effect on images that aren't displayed on the screen." >I don't know if that warning is correct or not (...) As far as I can tell, IM is not correct: drawing does get clipped to visRgn. I have fresh a recollection of creating an off-screen bitmap to produce image for printing and doing CopyBits to the printer port just to find out that I was getting 640x480 pixel image ... KK -- "The party was a masquerade; the guests were all wearing their faces."
parent@apple.com (Sean Parent) (08/22/89)
In article <1336@speedy.mcnc.org> kk@mcnc.org (Krzysztof Kozminski) writes: > As far as I can tell, IM is not correct: drawing does get clipped to visRgn. > I have fresh a recollection of creating an off-screen bitmap to produce image > for printing and doing CopyBits to the printer port just to find out that > I was getting 640x480 pixel image ... Inside Mac is correct. Drawing does not get clipped to visRgn on an off screen Bit/PixMap with one exception. StdBits (not CopyBits) will obey the visRgn. Most applications do not need to call StdBits directly so this is usually not a problem. Sean Parent
oster@dewey.soe.berkeley.edu (David Phillip Oster) (08/22/89)
When I tested it in 1987, Inside mac was wrong:
you had to set the visRgn to the portRect, if the the bitmap was bigger
than ScreenBits.bounds. And, it stands to reason that this should be so,
since how would quickdraw know that thePort is just a port and not a
window?
Further, you do a ClipRect(&thePort->portRect) not to clip the image to
the bitmap, QuickDraw will do that anyway, you do it, so if you record a
picture in that port, then do a DrawPicture to some other port, if you
adjust the location, a default clipRgn will overflow into an empty
rectangle.
Also, if you want fast drawing, create a pixMap the same depth as the
destination. Sure Quickdraw will convert it up or down, but it is much
faster to do it right yourself.
Check out my Griffeath color cyclic automata program (freeware, archived
on sumex-aim.stanford.edu) It uses optimized assemply language to diddle
am offscreen 8-bit deep pixmap, then calls CopyBits to display it. Notice
how much slower it runs if you set the screen to 4-bits per pixel instead
of 8.
--- David Phillip Oster 7 line signature follows
Keith Sproul, head of microcomputer support at Union Carbide, NJ, complained
about the poorly digitized fellatio on an IBM porno program. "Mac is better
on everything, and this is no execption." -- "Computer Porn at the Office"
by Reese Erlich, _This_World_, S.F. Chronicle, p.8, Aug 13, 1989
Arpa: oster@dewey.soe.berkeley.edu
Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edura_robert@gsbacd.uchicago.edu (09/03/89)
In article <3733@internal.Apple.COM>, parent@apple.com (Sean Parent) writes... > >Inside Mac is correct. Drawing does not get clipped to visRgn on an off >screen Bit/PixMap with one exception. StdBits (not CopyBits) will obey the >visRgn. Most applications do not need to call >StdBits directly so this is usually not a problem. > Could someone from Apple (DTS?) clear this up once and for all? I've been told many times (and my experience has shown) that drawing _does_ get clipped to the visRgn when using an offscreen bitmap -- and not just when calling StdBits (which I've never used). In fact the clipping to the visRgn was a bug that took me a while to track down in one of my programs. So: is IM right, wrong, or what? Enquiring hackers want to know. Robert ====== ra_robert@gsbacd.uchicago.edu ============================= generic disclaimer: all my opinions are mine