steele@unc.cs.unc.edu (Oliver Steele) (05/09/88)
I need to save a color bitmap as a PICT file. Here's what I've tried: 1) Opening a CGrafPort and a picture, doing a CopyBits from the port to itself, closing the picture, and saving it to disk. For a 640x480 picture, this bombs during the CopyBits, even with 5M of memory, whether I've called MaxApplZone or not. QuickerGraf is enabled, for what that's worth. 2) Same as (1), but CopyBitsing in bands. This works perfectly, even when all the CopyBits are wrapped in a single picture, but it doubtless makes a larger PICT file than necessary, and it definitely takes longer to draw than... 3) Same as (1), only change the port's grafProcs to one that's been initialized with SetStdCProcs, and change the grafProcs' putPicProc as per IM5. (LSC bug: a CGrafPort's grafProcs is defined as a QDProcsPtr instead of a CQDProcsPtr.) This is pretty much straight from IM5, so I doubt I've messed this up. This also works perfectly, and gets me a much smaller PICT file than (2), but the color table is all wrong. This is true even if I use an OpenCPort to open both the port I'm copying from when I make the file and the one I'm copying to when I display it, or if I use another program to display the PICT file. Also, for fairly small rectangles (say 10x10), an application that tries to display the PICT file locks, but I suspect this is an independent bug. Although I'd like to know why (1) bombs and (2) doesn't, I'd really like to spool the pictures instead of doing (1) or (2) since I want them on disk anyway and I don't want to need a half meg MF partition. Has anybody done (3) successfully, for color pictures? --------------------------------------------------------------------------- Oliver Steele ...!decnet!mcnc!unc!steele UNC-CH steele@cs.unc.edu "We made it structured, and now it doesn't work." -- Brice Tebbs
kaufman@polya.STANFORD.EDU (Marc T. Kaufman) (05/09/88)
In article <2620@thorin.cs.unc.edu> steele@unc.UUCP (Oliver Steele) writes: >I need to save a color bitmap as a PICT file. Here's what I've tried: [trials deleted] > (LSC bug: a CGrafPort's grafProcs is defined as a QDProcsPtr >instead of a CQDProcsPtr.) This is because the first routines in a CQDProcs list are identical to the routines in a QDProcs list, and if you are only going to change, e.g. TextProc, you don't have to check the Graf type or Ptr type (Apple seems to do this lots of places, not just here). To get back to the original problem: Why not open a NEW CGrafPort, with NO storage for the PixMap (portRect = (0,0,0,0)), and spool to that. It works, and gains back the space you had allocated to the PixMap. I think that if this is an Offscreen GrafPort, the color table will be saved to the spool file, since it is not the same as the source color table (you may have to twiddle the CLUT ctSeed in the Offscreen port to convince QuickDraw this is the case). Marc Kaufman (kaufman@polya.stanford.edu)
steele@unc.cs.unc.edu (Oliver Steele) (05/11/88)
kaufman@polya.Stanford.EDU (Marc T. Kaufman) writes: >In article <2620@thorin.cs.unc.edu> steele@unc.UUCP (Oliver Steele) writes: > >> (LSC bug: a CGrafPort's grafProcs is defined as a QDProcsPtr >>instead of a CQDProcsPtr.) > >This is because the first routines in a CQDProcs list are identical to the >routines in a QDProcs list, and if you are only going to change, e.g. >TextProc, you don't have to check the Graf type or Ptr type (Apple seems to >do this lots of places, not just here). I don't see that this can work. You're always going to need to put a pointer to a CQDProcs in a CGrafPort's grafProcs, and not a pointer to a QDProcs, because Quickdraw can't tell the size of the structure the grafProcs is pointing to. A QDProcs doesn't have room for the opcodeProc and newProcs, so Color Quickdraw will jump to a random address if you use a QDProcs' address here and it runs across a need for these. The other way around works: you can always allocate a CQDProcs and then call SetStdProcs on a pre-II, GetStdCProcs on a color machine, and put the address of your modified CQDProcs in your port. But it seems that it's NEVER all right to use a QDProcsPtr in a CGrafPort, so why declare it that way? On to better things: >>I need to save a color bitmap as a PICT file. Here's what I've tried: [trials deleted, but basically my colors get munged] >To get back to the original problem: Why not open a NEW CGrafPort, with >NO storage for the PixMap (portRect = (0,0,0,0)), and spool to that. It >works, and gains back the space you had allocated to the PixMap. I think >that if this is an Offscreen GrafPort, the color table will be saved to >the spool file, since it is not the same as the source color table (you may >have to twiddle the CLUT ctSeed in the Offscreen port to convince QuickDraw >this is the case). Thank you for the suggestion; it really looked like it ought to work. It gets me the same results as copying to the on-screen CGrafPort, however: if I copy in bands, the color in the saved PICT is right; if I copy the whole Rect at once (and Rect can be as small as 100x100 for this effect to hold; I haven't yet tried to find the boundary), color gets munged. And this is true even for a new ctSeed. (Don't forget HandToHand when you want a copy of a color table!) I'll tell y'all (yes, I'm Southern) when I solve this. --------------------------------------------------------------------------- Oliver Steele ...!decnet!mcnc!unc!steele UNC-CH steele@cs.unc.edu "The screen is a window through which one sees a virtual world. The challenge is to make that world look real, act real, sound real, feel real." -- Ivan Sutherland, 1965