Subject:
RE: NanoGUI palette model
From:
Greg Haerr ####@####.####
Date:
28 Sep 1999 17:24:19 -0000
Message-Id: <01BF09A3.94C83050.greg@censoft.com>
: 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.
Yep
: - When setting drawing color etc., you user COLORVAL's. COLORVAL is
: an at least 32 bit integer.
COLORVAL is always a 32 bit RGB format color value. If F_PALINDEX
is set, then it's an index into the current palette. Otherwise, mwin converts
the requested RGB value into a closest-matched color in the currently defined
system palette. The system palette is reloaded on occasison my mwin to
support 256 color pictures, etc. Microwindows manages all system
palette requests, and starts by defining a small 48 color palette (or smaller
if devpal4 or similar is linked in) This allows user programs to negotiate with
predefined palettes, or have completed control of the color display.
: - If we're drawing on a true type (I assume including 15,16,24 and 32 bit
: displays?
Currently, there's no support for 15 or 16 bit displays, but it'd be easy
to add.
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.
PIXELVAL needs to become an unsigned long to support running
on truecolor displays. I was about to add this, but I can't the damn aty
framebuffer on my system to run in truecolor... Anyway, there needs to be
a compile-time option to support truecolor or not, so that on smaller 16 bit systems
PIXELVAL doesn't have to be a long, thus slowing drawcode quite a bit.
If compiled for 24 or 32 bit truecolor, then the RGB COLORVAL
can be "passed thru" directly to the COLORVAL, in GdFindColor. We still
want to call the function, for top-level reasons. This should be very simple
to add.
: - 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.
Yes. F_PALINDEX is not recomended, since the user application
doesn't normally know how big the palette is, and shouldn't be recompiled,
but I providied this for backwards compatibility with nano-X programs, and defined
all the standard colors in this way. All the devpalX.c palettes have a required
color order for the first 8, then first 16 colors.
: - GdFindNearestColor() approximates the RGB value given, to a value in
: the palette.
Normally, yes. However, other routines may add the RGB value to
the system palette, if there's room.
: - 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.
The palette merge code currently assumes that the user program
knows when it will need to display two different 256 color bitmaps simultaneously,
and will call a system palette reset function in between...
:
: 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.
A _far_ better idea would be too merge pre3 into 0.83, since there's tons
of other additions and bug fixes since then. All the nanoX stuff works in 0.83,
and is under the src/nanox directory. I don't think there's many changes, other
than the filename/directory name changes Alex introduced. All the driver
model interfaces have been updated too, and pre3 won't run on anything but 32-bit
framebuffer machines, not ELKS or SVGAlib.
:
: 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 thought of this, and figured it wasn't time yet to introduce a complicated
driver model yet. This makes porting much harder. On strange displays, a
special devpalX.c can be built, and still use distance-cubed RGB matching to
get to the hw PIXELVAL color.
: - 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.
Well, that's why F_PALINDEX is in the upper 8 bits of 32. But
all colors for applications should be COLORVALs, which include RGB
or palette indices, as 32 bit values.
:
: 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.
Definitely. The design is that user programs will run unmodified on
various hardware, without knowledge of it. That's why I chose RGB. F_PALINDEX
is of limited usefulness, but is quite fast and the standard colors defined in device.h
all work on any device.
:
Greg
