ddisabat@deimos.ADS.COM (David Disabatino) (04/29/89)
I am having some trouble with Copybits used to copy a pixmap into
a window pixmap. I have created a pixmap for an image loaded in.
The data is in a nonrelocatable block in the heap. I create a
pixmap for the image (8 bits / pix)
pixhndl = NewPixMap();
(**pixhndl).rowBytes = image.width;
(**pixhndl).bounds = StuffRect(0, 0, image.width, image.length);
(**pixhndl).baseAddr = (Ptr)image.data;
image.pmap = pixhndl;
Then I try to copybits this pixmap onto a window.
SetRect(&srcrect, 0, 0, image.width, image.length);
SetRect(&dstrect, 0, 0, image.width, image.length);
CopyBits(image.pmap, &srcrect, win->portPixMap, &dstrect, srcCopy, NULL);
It doesn't crash or anything, but I see no visible results on screen.
Maybe the call to CopyBits is wrong? But any other combination of
args gives compiler errors. Is it legal to set up a pixmap like this
without a GrafPort. I know the data is there, because if I physically
write it into the window pixmap it appears on screen, albeit rather
slowly.
for (i = 0 ; i < img.length ; i++)
for (j = 0 ; j < img.width ; j++)
*((**win->portPixMap).baseAddr + j +
(i * ((**win->portPixMap).rowBytes & 0x1FFF))) =
*(img.data + j + (i * img.width));
This works fine. Of course there are a few casts in the above staement.
Please if anyone knows how to copy pixmaps, clue me in.
thanks
ddrainero@prism.wbst128.xerox.com (Emil Rainero) (05/01/89)
In article <7731@zodiac.UUCP> ddisabat@ads.com (David Disabatino) writes: >I am having some trouble with Copybits used to copy a pixmap into >a window pixmap. I have created a pixmap for an image loaded in. >The data is in a nonrelocatable block in the heap. I create a >pixmap for the image (8 bits / pix) > >Then I try to copybits this pixmap onto a window. >SetRect(&srcrect, 0, 0, image.width, image.length); >SetRect(&dstrect, 0, 0, image.width, image.length); >CopyBits(image.pmap, &srcrect, win->portPixMap, &dstrect, srcCopy, NULL); > >It doesn't crash or anything, but I see no visible results on screen. >Maybe the call to CopyBits is wrong? But any other combination of >args gives compiler errors. Is it legal to set up a pixmap like this >without a GrafPort. I know the data is there, because if I physically >write it into the window pixmap it appears on screen, albeit rather >slowly. > >This works fine. Of course there are a few casts in the above staement. >Please if anyone knows how to copy pixmaps, clue me in. This looks like one of those problems easily solved with ANSI prototypes. pascal void CopyBits(BitMap *srcBits, BitMap *dstBits, Rect *srcRect, Rect *dstRect, int mode, RgnHandle maskRgn); >CopyBits(image.pmap, &srcrect, win->portPixMap, &dstrect, srcCopy, NULL); ^ ^ Looks like you have the srcrect and win->portBitMap pointers reversed. I also recall reading that CopyBits wants at most 32K of data. (might want to read the IM V.1 section on CopyBits. The ANSI prototypes for almost all of Inside Mac Vol I-V are on sumex and could be reposted here if necessary. Lightspeed does an excellent job with the real ANSI prototypes and precompiling them with the common mac includes seems to cost about 1 second to load on each compile (about the same time as a very short .h file). There really is no reason not to do this. While it is a pain to explicitly typecast many simple calls to get them to conform, the alternative is at best a debugging session that bombs on the offending line and at worst a hung mac (yes, even with the source level debugger). Why does LSC not include ANSI prototypes for all MAC and non-mac functions? I use the protos for the standard library functions but I could not find a prototype for Debugger(). This caused a lot of grief because I remembered invoking Debugger(char *) in the pat and this new debugger call is Debugger(void). Emil
jamesm@sco.COM (James M. Moore) (05/04/89)
In article <741@rocksanne.UUCP> rainero@prism.UUCP (Emil Rainero) writes: >I also recall reading that CopyBits wants at most 32K of data. (might want >to read the IM V.1 section on CopyBits. Actually, it says that the Quickdraw convention is to not use more than 3k of stack space. I presume that's to avoid possible stack overflows. My question: how does one find out what the bottom of the stack should be? Seems like you could just check A7 against that number, and if there's room go ahead and copy more than 3k. I've been copying the entire screen in one pass, and haven't noticed any problems (about 18k per copybits call). -- ** James Moore ** ** Internet: jamesm@sco.com ** ** uucp: {decvax!microsoft | uunet | ucbvax!ucscc | amd}!sco!jamesm ** ** Nil clu no suim ar bith ag SCO ceard a bhfuil me ag scriobh anois. **
darin@Apple.COM (Darin Adler) (05/04/89)
In article <2852@viscous.sco.COM> jamesm@sco.COM (James M. Moore) writes: > In article <741@rocksanne.UUCP> rainero@prism.UUCP (Emil Rainero) writes: > >I also recall reading that CopyBits wants at most 32K of data. (might want > >to read the IM V.1 section on CopyBits. > > Actually, it says that the Quickdraw convention is to not use more > than 3k of stack space. I presume that's to avoid possible stack > overflows. My question: how does one find out what the bottom of the > stack should be? Seems like you could just check A7 against that > number, and if there's room go ahead and copy more than 3k. I've been > copying the entire screen in one pass, and haven't noticed any > problems (about 18k per copybits call). This warning is fairly obsolete. The stuff regarding CopyBits and 3K in Inside Macintosh refers to CopyBits calls that are being accumulated into a picture. Since then, bitmap/pixmap accumulation into pictures has been enhanced, so the 3K limit no longer applies. to -- Darin Adler, System Software Scapegoat, Apple Computer Internet: darin@Apple.com UUCP: {nsc,sun}!apple!darin