jackiw@cs.swarthmore.edu (Nick Jackiw) (03/08/90)
I've been knocking myself out over a simple (stupid) question: I want to copyBits from one pixmap to another without using any cGrafPorts. How? IM V says "CopyBits now accepts either bitMaps or pixMaps as parameters." Obviously, CopyBits(pixMapHandle^^,pixMapHandle^^,...) isn't going to work; pixMapHandle^^ is not the same type as BitMap, and even if I coerce it into so believing, with CopyBits(BitMapHandle(PixMapHandle)^^,) I'm hacking off many of the fields of the pixMap (including important ones like pixelDepth) and I get stack overflows, bus errors, and other symptoms of the Wrong Approach. In that thePort^.portBits can still be passed, and that its format is now thePort^.portBits equivalent bytes in cGrafPort baseAddr PortPixMapHandle; rowBytes portVersion bounds grafVars I assume copyBits checks the rowBytes of a passed bitmap to see if (two high bits set) the baseAddr contains a pixMapHandle or if (two high bits clear) the baseAddr contains a regular bit-map bit-image. Thus I'd assume that aBitMap:=thePort^.portBits (where thePort is pointing to a cGrafPtr, not a grafPtr), would fill in the appropriate values for copyBits to know it was getting a pixMap, and then aBitMap.baseAddr:= ptr(myPixMapHand) before CopyBits would tell it which bitMap. Also not so--while the system errors stop, the results aren't right either (the offscreen pixmap, when copied, copies as ultra-slow all black regardless of the contents of its baseAddr field). NEITHER OF THESE METHODS ARE RIGHT. WHAT'S THE RIGHT WAY? (Or must I use a pixMap embedded in a port? What a shameful waste.) Thanks! -- ------------------------ Nick Jackiw jackiw@cs.swarthmore.edu "Just break out the Visual Geometry Project jackiw@swarthmr.bitnet rum so we seem natural!" Swarthmore College, PA 19081-1397 -F. Franklin
oster@well.sf.ca.us (David Phillip Oster) (03/11/90)
In article <KKZF972@xavier.swarthmore.edu> jackiw@cs.swarthmore.edu (Nick Jackiw) writes:
_>I've been knocking myself out over a simple (stupid) question:
_>I want to copyBits from one pixmap to another without using any cGrafPorts.
_>How?
_>IM V says "CopyBits now accepts either bitMaps or pixMaps as parameters."
_>Obviously, CopyBits(pixMapHandle^^,pixMapHandle^^,...) isn't going to work;
_>pixMapHandle^^ is not the same type as BitMap, and even if I coerce it
_>into so believing, with CopyBits(BitMapHandle(PixMapHandle)^^,) I'm
_>hacking off many of the fields of the pixMap (including important ones
_>like pixelDepth) and I get stack overflows, bus errors, and other symptoms
_>of the Wrong Approach.
The correct call is:
HLock(Handle(srcPixMapHandle));
HLock(Handle(destPixMapHandle));
CopyBits(BitMapHandle(srcPixMapHandle)^^,
BitMapHandle(destPixMapHandle)^^,
srcRect, destRect, srcCopy, NIL);
HUnlock(Handle(srcPixMapHandle));
HUnlock(Handle(destPixMapHandle));
CopyBits will look at the rowBytes field and do the right thing.
(or, it will look at the version field an do the right thing.)
But, it will move memory, so you have to lock the pixMapHandles acorss the
call. If you remember your Inside Mac Vol 1. Assem. Lang. Interface.,
large structures are passed by reference in pascal, so you are not chopping
off anything important. The stucture of a pixmap was designed specifically
to make this work.
Note: this uses the inverse table of the current Graphic Device to do
color table arbitration if the two pixmaps use different color tables.
--
-- David Phillip Oster - Note new address. Old one has gone Bye Bye.
-- oster@well.sf.ca.us = {backbone}!well!osterph@cci632.UUCP (Pete Hoch) (03/13/90)
> Nick Jackiw writes: > _>I've been knocking myself out over a simple (stupid) question: Question about using PixMapHandles in Copybits. David Phillip Oster replies: > The correct call is: > HLock(Handle(srcPixMapHandle)); > HLock(Handle(destPixMapHandle)); > CopyBits(BitMapHandle(srcPixMapHandle)^^, > BitMapHandle(destPixMapHandle)^^, > srcRect, destRect, srcCopy, NIL); > HUnlock(Handle(srcPixMapHandle)); > HUnlock(Handle(destPixMapHandle)); I have some friends who disagree with this and I will try to argue their point. Who said you have to lock the handles before calling CopyBits? I have never seen sample code from Apple that does this. In fact the brand new publication from Apple "Develop" has code samples that use CopyBits with PixMapHandles and they DO NOT lock the Handles. I think, but have no proof that CopyBits checks the Bit/PixMap type, (it has to do this anyway) and if it is a PixMapHandle then CopyBits takes care of the memory management problems, (if there are any) for you. An example: CopyBits( myOffscreen^.portBits, thePort^.portBits, ... The global thePort may be pointing to a GrafPort or to a CGrafPort I don't know which, therefore CopyBits must take care of it for me. As I said before, I do not believe this but my friends do. Unfortunately I have not been able to convince them. So any ideas why this is wrong? Or is it right? Pete Hoch
russotto@eng.umd.edu (Matthew T. Russotto) (03/14/90)
In article <34996@cci632.UUCP> ph@cci632.UUCP (Pete Hoch) writes: >> Nick Jackiw writes: >> _>I've been knocking myself out over a simple (stupid) question: > >Question about using PixMapHandles in Copybits. > >David Phillip Oster replies: >> The correct call is: >> HLock(Handle(srcPixMapHandle)); >> HLock(Handle(destPixMapHandle)); >> CopyBits(BitMapHandle(srcPixMapHandle)^^, >> BitMapHandle(destPixMapHandle)^^, >> srcRect, destRect, srcCopy, NIL); >> HUnlock(Handle(srcPixMapHandle)); >> HUnlock(Handle(destPixMapHandle)); > >I have some friends who disagree with this and I will try to argue >their point. Who said you have to lock the handles before calling >CopyBits? I have never seen sample code from Apple that does this. >In fact the brand new publication from Apple "Develop" has code >samples that use CopyBits with PixMapHandles and they DO NOT lock >the Handles. I think, but have no proof that CopyBits checks >the Bit/PixMap type, (it has to do this anyway) and if it is a >PixMapHandle then CopyBits takes care of the memory management >problems, (if there are any) for you. Lock the handles. Portbits is a special case-- you pass it a POINTER to a HANDLE to a PIXMAP, instead of the usual pointer to PixMap or pointer to BitMap. I think Copybits detects this situation. And before someone at DTS jumps all over me for this, I've tried it. -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu ][, ][+, ///, ///+, //e, //c, IIGS, //c+ --- Any questions?