nanogui: NanoGUI palette model
Subject:
Re: NanoGUI palette model
From:
"Vidar Hokstad" ####@####.####
Date:
29 Sep 1999 12:50:07 -0000
Message-Id: <19990929124520.26882.qmail@mail.relight.com>
On Wed, 29 Sep 1999 08:26:31 -0400 you wrote:
>----- Original Message -----
>From: Vidar Hokstad ####@####.####
>To: ####@####.#### ####@####.####
>Cc: ####@####.####
>Sent: Wednesday, September 29, 1999 4:54 AM
>Subject: RE: NanoGUI palette model
>
>
>> What I'm suggesting is only that if TRUECOLOR is defined that we get the
>> RGB value from the palette if F_PALINDEX is set, so that palettes
>(including
>> user defined) work on truecolor displays too.
>
>Are the palettes all static, defined by the driver? If so, then driver
>itself can map a passed palette index to RGB.
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.
>Even if someday drivers allow modification of the hardware palette, the
>driver can still map RGB to index itself.
>
>The only value I see to the palette index flag is to have 8 or 16 "standard"
>colors that programs can count on, but even that is kind of superfluous -
>they can just specify a "standard" RGB (black, white, yellow, green, etc.
>like Netscapes color names) and let the driver do its best.
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.
>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.
Regards,
Vidar
