dplatt@coherent.com (Dave Platt) (09/29/88)
I have an application (a fractal-generating program) that frequently
needs to display a large amount of data into a color window.
Originally, the program drew the data pixel-by-pixel (with some run
optimization) via standard Color QuickDraw methods... each scan-line
required a MoveTo() call, followed by a series of PMForeColor() and
LineTo() calls. Because the number of different colors in use is
relatively large (>200/image), this method tended to require many
PMForeColor() and LineTo() calls, and was (as you can guess) Pretty
Darned Slow.
I've substantially increased the speed of the screen-drawing by doing
the pixel-stuffing in a more efficient way which still appears to
follow The Rules. I set up a temporary CGrafPort, allocate a large
PixMap for this port, copythe current GDevice's color map, and tweak
the copy of the map to indicate that it's a PixMap map rather than a
GDevice map. This process follows the steps for drawing into an
off-screen PixMap, as suggested in Tech Note 120 and Scott Knaster's
second book. Then, I use a trick related by Ed Tecot some months ago:
I call Color2Index for each of the colors that I want to use, record
the color-index for each color, and simply stuff these indices into the
appropriate pixels in my off-screen PixMap. Once I've filled the
PixMap, I simply CopyBits() it to the appropriate portion of my color
window, and the image appears with all the correct colors. This
process is much faster than the standard QuickDraw-it-to-the-window
method.
I've run into a stumbling block, however, and I wonder if any of you
Wizards Of Space And Time can point me to a solution:
I'd like to do this same "stuff values into an off-screen PixMap and
then CopyBits to the screen" trick, while using a palette full of
animating colors (rather than tolerant colors, as I had been using). I
can't figure out a way [that I like and consider safe] to identify the
correct color indices.
I can create a palette full of animating colors with no trouble at all,
and if I use the standard Color QuickDraw drawing techniques,
everything works fine. However, I don't believe that I can use the
off-screen PixMap trick in its current form, because (as I understand
it) Color2Index does not consider animating entries in the device's
CLUT as being acceptable matches for any RGBColor.
I can think of a few kludges to identify the appropriate indices, but I
don't really like any of 'em:
1) Poke into the private (undocumented) Palette Manager data in the
destination window's palette, and somehow deduce the correct
color-table index. [Ugly, and prone to break if the Palette Manager
ever changes.]
2) Perform a PMForeColor() for each desired animating color, and steal
the index out of the CWindow structure. [Once again, ugly and prone
to break in the future.]
3) Actually draw a pixel full of the desired animating color into the
destination window, and then look into its PixMap, grab the pixel,
and remember its value. [Probably workable, but inelegant.]
A question for the gurus: is there _any_ clean, safe and elegant way
to figure out the actual color-table index of an animating color in a
window's palette?
--
Dave Platt VOICE: (415) 493-8805
USNAIL: Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303
UUCP: ...!{ames,sun,uunet}!coherent!dplatt DOMAIN: dplatt@coherent.com
INTERNET: coherent!dplatt@ames.arpa, ...@sun.com, ...@uunet.uu.net