From: mhall@occs.cs.oberlin.edu (Matthew Hall)
Subject: Re: The Pallette manager
Organization: Oberlin College Computer Science
Distribution: comp.sys.mac.programmer
Date: Fri, 11 Sep 1992 21:28:09 GMT
X-Posted-From: occs.cs.oberlin.edu
X-Posted-Through: sol.ctr.columbia.edu

In article <1992Sep11.181806.10762@waikato.ac.nz> ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes:

>
>   >  This way, I can
>   > draw directly into the offscreen map since the positions of the colors
>   > in the clut don't change, and I don't have to use
>   > pmtolerant+pmexplicit, or setentries, and I can draw in an ideal color
>   > environment and let PM take care of tolerance and updates.
>
>   Hang on--you don't need a palette for an offscreen port. The main point of
>   palettes is for use with on-screen windows. The only point with attaching
>   a palette to an offscreen port would be so you can use PmForeColor and
>   PmBackColor to quickly specify colours from the palette. Tolerant and
>   animated entries don't mean anything in an offscreen palette.
>
I should have been clearer.  I load a 256 color pallette from a
resource file with GetCTable.  Then I set
Offscreen^.portpixmap^^.pmtable equal to that clut.  Then, I create a
palette for the current screen depth, and fill it with values from the
clut.  The palette is only for the window that the plot will
eventually be displayed in.  I draw in the offscreen pixmap by
directly setting the bytes.  If I loaded a gray scale, then the level
of gray is from 0-255.  I just place that byte in the pixmap data.
When I am done, I call copybits from the port to the screen.



>   What exactly *is* your method? If you're directly poking colour table
>   entries, are you remembering to call CTabChanged so QuickDraw knows what
>   you've been up to? 

No I haven't.  I didn't even know I was supposed to.  Thanks.

>If you want a custom colour table for your pixmap, then
>  *YES*, you *DO* have to create a custom GDevice. This is because the mapping
>  from the colours you ask for to actual pixel values is done using an inverse
> colour table, and you find those in the GDevice structure, not in the PixMap.
>
>Are you using the GWorld routines? If not, I highly recommend them. Here's how
>   you create a GWorld:

The problem is that I want this to be compatible with as many
computers as it can.  GWorlds are only in sys 7 and 32 bit quickdraw
equipped Macs.  Inhibited colors are only in systems 6.0.5 and later.
I may be able to assume that anyone running color should be running
6.0.5, so maybe I will use inhibited colors, and just create one
palette, but I don't want to assume system 7, or 32-bit QD.
Of course, my compatibility concerns are worthless if my method
crashes most computers or graphics cards.  It works on an LC tho'

I guess I will have to create a gDevice for the offscreen port then.
The only quickdraw call I make, besides copybits, is fillrect though.
Otherwise I just poke in numbers.  it seems kind of a waste of memory
to create a GDevice just for FillRect when otherwise things seem to be
working well.  I can't see any problems with accelerator cards since I
don't modify screen data directly.  

Thanks for the help
-matt hall

--


-------------------------------------------------------------------------------
Matt Hall.    mhall@occs.cs.edu  OR  SMH9666@OBERLIN.BITNET
              (216)-775-5805 (That's a Cleveland Area code. Lucky Me)

"If a man comes up to you and says:
	'A dog just carried away your ear.'
Do you run after the dog, or search first for your ear?" - Moon over Morocco