nanogui: NanoGUI palette model


Previous by date: 29 Sep 1999 18:06:31 -0000 Re: State of the nanogui union?, Greg Haerr
Next by date: 29 Sep 1999 18:06:31 -0000 Re: Cleaning up the source trees, Alex Holden
Previous in thread: 29 Sep 1999 18:06:31 -0000 Re: NanoGUI palette model, Bradley D. LaRonde
Next in thread: 29 Sep 1999 18:06:31 -0000 Re: NanoGUI palette model, Greg Haerr

Subject: RE: NanoGUI palette model
From: Greg Haerr ####@####.####
Date: 29 Sep 1999 18:06:31 -0000
Message-Id: <01BF0A71.669F4780.greg@censoft.com>

: As far as I can see from Gregs code there are two palettes: The driver
: palette, which is static, and the system palette, which can be modified.
: The system palette maps 8 bit indexes into the system palette into
: whatever is the closest matching PIXELVAL, which may be the RGB value,
: or an index into the drivers palette.

	Almost, Vidar.  (You're doing great, though)  There's really only
one palette, the one linked in devpalX.c.  This palette starts out static,
with a "bar" indicating the "system" colors.  Below the bar are system
colors, above, user-defineable.  The bar starts at approximately 24.  (FIRSTUSERPALETTEENTRY)
When the bar increments, the device driver is called to set a new system
palette from the linked in palette.  Every time this raises, the hw
palette is modified, until there's no more entries.  The user program can
reset the palette (user entries) with the GdResetPalette() call.  The
GdDrawImage call will merge/build palette entries according to
an internal algorithm.

: 
: It's often convenient to use palettes anyway. For instance with pixmaps
: which actually have only a few colors. And forcing the drivers to do
: color conversion every time isn't very efficient performance wise.
:  

	I agree.


: >As for the differences in mapping between RGB bit layouts, again, the driver 
: >can do the mapping, no? 
: 
: They can, but it's not efficient. The point of mapping it in GdFindColor
: would be that you can build up a cache of PIXELVAL's corresponding to the
: appropriate color, and not have to convert for each and every operation.
: Thus, IMHO, GdFindColor() should return the most efficient way of
: representing the color for the hardware driver, not something that will
: have to be converted yet another time.
: 
	Exactly.  This is also extremely important when we move to 
bitblt's which are PIXELVAL->PIXELVAL moves.  The nano-X ReadArea8()
function relies on this.

Greg

Previous by date: 29 Sep 1999 18:06:31 -0000 Re: State of the nanogui union?, Greg Haerr
Next by date: 29 Sep 1999 18:06:31 -0000 Re: Cleaning up the source trees, Alex Holden
Previous in thread: 29 Sep 1999 18:06:31 -0000 Re: NanoGUI palette model, Bradley D. LaRonde
Next in thread: 29 Sep 1999 18:06:31 -0000 Re: NanoGUI palette model, Greg Haerr


Powered by ezmlm-browse 0.20.