nanogui: NanoGUI palette model
Subject:
RE: NanoGUI palette model
From:
Greg Haerr ####@####.####
Date:
29 Sep 1999 17:42:38 -0000
Message-Id: <01BF0A6E.7EA9F0D0.greg@censoft.com>
: Are the palettes all static, defined by the driver? If so, then driver
: itself can map a passed palette index to RGB.
:
The palettes are all defined by mid-level microwindows code,
and one is linked in statically according to which screen driver is linked in.
: Even if someday drivers allow modification of the hardware palette, the
: driver can still map RGB to index itself.
:
The drivers currently depend on modification of the hardware palette,
Vidar was slightly incorrect (although he's done damn good job of decoding my code).
If the hw can't support hw palettes, you just link in your own special devpalX.c
that matches RGB values (4 bit gray scale for Clio) to palette values, and the driver
can ignore setpalette calls.
: 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.
That's exactly the reason I added the palette index flag, so that
MicroWindows can depend on some standard colors, and so can the widgets.
Now, another cool feature that nobody's noticed yet is that microwindows
supports color schemes for the controls, and a single call can allow the entire
desktop color scheme to change. This is very useful for systems that
run only grayscale rather than color... as well as just more color variety for people
who like change...
:
: As for the differences in mapping between RGB bit layouts, again, the driver
: can do the mapping, no?
:
Yep, although we're talking about having the mid-level do some
standard processing, as discussed in an earlier email.
Greg
