copying picts

frac707
Unregistered
 
Post: #1
Hi,

I'm trying to implement an undo command in my Carbon program. Part of this requires copying the current picture (pict) to an undobuffer. I can allocate the undobuffer, but I don't know how to copy the picture from the active window to it, or how to copy the picture from the undobuffer to the active window (windowRef). I allocate the undobuffer like so:

(*docStrucHdl)->undopictureHdl = (PicHandle) NewHandle(320*480*32+512);

I'm not sure that this is correct. The pict resource is for a 480X320 window. What I need to do is copy the contents of (*docStrucHdl)->pictureHdl to (*docStrucHdl)->undopictureHdl, and then the reverse (to undo). This might be done by getting the pointer to the data in (*docStrucHdl)->pictureHdl, but how is that obtained from the picture handle?
Quote this message in a reply
frac707
Unregistered
 
Post: #2
The correct syntax for copying picts seems to be:
(*(*docStrucHdl)->pictureHdl)=(*(*docStrucHdl)->undopictureHdl);
Then:
DrawPicture( (*docStrucHdl)->pictureHdl,&pictureRect);
to redraw the window.

But is it correct to add 512 bytes to the size (for user data) when allocating the pict structure?

"(*docStrucHdl)->undopictureHdl = (PicHandle) NewHandle(320*480*32+512);"

Is the picture data 32 or 16 bit for a color pict or something else? I'm used to dealing with true color bitmaps where the pixels are 32 bit. It probably doesn't matter if the allocation is oversized, but I'd rather not guess on this...
Quote this message in a reply
frac707
Unregistered
 
Post: #3
Okay, I posted some silly questions. I'm new to the Mac environment... Picture aren't the same as bitmaps and it depends on how many QuickDraw commands are in the data to determine how much memory to allocate for an undobuffer. But one thing is still puzzling me, and that is how to manage memory for QuickDraw pictures.

This is a long explanation of the problem. Maybe someone will have the patience to read it through and give me an answer.

First off, a pict is loaded with the document, and memory is allocated for the pict handle based on the data in the file:

GetEOF(fileRefNum,&numberOfBytes);
SetFPos(fileRefNum,fsFromStart,512);
numberOfBytes -= 512;
if(!((*docStrucHdl)->pictureHdl = (PicHandle) NewHandle(numberOfBytes)))
return MemError();

The undobuffer is also allocated at a fixed size :

(*docStrucHdl)->undopictureHdl = (PicHandle) NewHandle(240*180*32+512);

For a 240X180 window, this is about the maximum number of QuickDraw data bytes that could ever be generated with my drawing routine. (I use one moveto() and one lineto() command for each pixel, since SetCPixel doesn't seem to work with OpenCPicture).

The main picture data is saved in the undobuffer, then the picture handle is used with OpenCPicture to generate a new picture:

(*(*docStrucHdl)->undopictureHdl)=(*(*docStrucHdl)->pictureHdl);
(*docStrucHdl)->pictureHdl = OpenCPicture(&picParams);
....... (QuickDraw commands)
ClosePicture();
...... (cleanup)
DrawPicture( (*docStrucHdl)->pictureHdl,&pictureRect);

The picture is undone by:

(*(*docStrucHdl)->pictureHdl)=(*(*docStrucHdl)->undopictureHdl);
DrawPicture( (*docStrucHdl)->pictureHdl,&pictureRect);

How does this work? -- because it definitely seems to work, and nothing else does. Are there memory leaks doing this? If I Kill the picture structure before using the picture handle with OpenCPicture, then the program crashes when I try to undo the picture as above. So OpenCPicture doesn't seem to allocate any extra memory for the pict structure. But how is this possible? As it stands now, the undobuffer's data may be larger than the picture memory, and I'd expect a crash if the picture memory didn't have at least enough bytes to hold the undobuffer data. Yet when I exit the drawing routine with only part of a drawing done, the data in the pict structure has to be smaller. But that doesn't seem to matter. The undoing works perfectly. Why doesn't it crash?

Note: This is my first program on Mac, so I'm using pictures instead of bitmaps because the code seems easier to implement than "graphic worlds". The images are only used as index files, so any format to save the images would do. (I have code for the PNG format from Windows, but there's a lot of files involved and they may not compile so easily with CodeWarrior. )
Quote this message in a reply
Moderator
Posts: 771
Joined: 2003.04
Post: #4
QuickDraw is being deprecated in Tiger. If you want to draw an image pixel by pixel it may be easier (and faster) to generate a buffer in memory, make a simple putPixel(x,y) macro and then copy that to the window.
As for saving images, there are a lot of Carbon and Cocoa routines you could use, try doing a search for "saving images" in ADC.
Quote this message in a reply
frac707
Unregistered
 
Post: #5
Thanks for your tips. I've been using the picture routines because I have sample code that shows how to draw a picture and how to save it. I have sample code on how to generate an off-screen graphics world and copy that to the screen, but nothing that shows how to save the wndow bitmap. Actually the picture drawing is fast enough for a 240X180 window. Most of the drawing is done off-screen with OpenCPicture, so the only slowdown is due to non-graphical calculations. The picture files are larger than bitmap files would be though. I will look at ADC for save options for bitmaps. BTW, no memory leaks in ZoneRanger, so I must be doing the pictures right.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Copying Projects and Files mikey 4 2,516 Jul 28, 2009 10:42 AM
Last Post: AnotherJake
  Noob: Copying Classes hangt5 3 3,456 Mar 9, 2005 12:52 PM
Last Post: codemattic
  Aligning two picts on an Angle SethWillits 3 2,498 Jun 22, 2003 11:46 PM
Last Post: SethWillits