nanogui: NanoGUI palette model
Subject:
NanoGUI palette model
From:
"Vidar Hokstad" ####@####.####
Date:
28 Sep 1999 11:39:19 -0000
Message-Id: <19990928113422.22128.qmail@mail.relight.com>
Hi,
I've started looking at whats required to combine the NanoGUI and Microwindows
drawing code (screen/common.c in Nano-X 0.5pre3 and devdraw.c in Microwindows
0.83), and most of the differences are related to the changed palette
model.
As far as I can see, the palette handling in MicroWindows is roughly like
this (Greg, correct me if I'm wrong, please...), some of which is shared
with Nano-X 0.5pre3:
- All drawing is based on PIXELVAL, which is an opaque representation
of color on whatever screen device you're operating on.
- When setting drawing color etc., you user COLORVAL's. COLORVAL is
an at least 32 bit integer.
- If we're drawing on a true type (I assume including 15,16,24 and 32 bit
displays? But I'm not sure if the code does any transformations, and
it seems like the code expects COLORVAL to hold a 24 bit R,G,B value
for truetype displays), then COLORVAL == PIXELVAL. We might want to
differentiate between different types of truetype displays, and convert
COLORVAL to the appropriate type.
- If we're drawing on a palette based display, all values above F_PALINDEX
is considered to be indexes into a palette. If not, GdFindNearestColor()
is called.
- GdFindNearestColor() approximates the RGB value given, to a value in
the palette.
- It has calls to merge palettes from for instance a color pixmap with
the system palette (which in truecolor would just be the same as the
original), to prepare for drawing a pixmap etc.
I suggest that we go for this palette model, with a couple of modifications,
and I volunteer to reintegrate this palette code into Nano-X 0.5pre3,
so that it and Microwindows shares the same palette code.
My suggested changes/concerns are these:
- As mentioned above, it might be worth converting from a single RGB
representation in GdFindColor(), to the hardware specific one. On the
other hand this might also be done in the driver. But especially with
regard to merging palettes, I'd expect that having the returned palette
be a set of hardware specific values would be most efficient. Comments?
- I'd like to treat truecolor the same as palette based systems with
regards to having an indexed palette. Since F_PALINDEX is defined
to be larger than any 24 bit RGB value, it's only a couple of lines.
That means that programs should work the same on both truecolor and
palette based systems: They either request a PIXELVAL corresponding
to a RGB value or a palette index, and the only difference is that
for truecolor displays the palette is software only.
Regards,
Vidar Hokstad
Screen Media AS
