nanogui: NanoGUI palette model
Subject:
RE: NanoGUI palette model
From:
"Vidar Hokstad" ####@####.####
Date:
29 Sep 1999 08:59:00 -0000
Message-Id: <19990929085413.25720.qmail@mail.relight.com>
On Tue, 28 Sep 1999 11:21:15 -0600 you wrote:
>: 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.
It doesn't have to be complicated. GdFindColor just has to know how to
map a 24 or 32 bit RGB value to the main types of RGB displays:
15/16/24/32 bits with different byte ordering. It can either be part of
GdFindColor, or we can add a function to the drivers to do it. If we're
going to support truecolor on all kinds of hardware it's something we'll
have to deal with anyway. Normally you just want to strip the least
significant bits and organize them correctly withing the 32 bit value.
>: - 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.
Yes, but currently, if TRUECOLOR is defined, it doesn't let you use the
palette - GdFindColor() just returns whatever value it's passed in and
assumes that COLORVAL == PIXELVAL for truecolor displays. First of all,
that isn't true for any displays that doesn't organize their color values
the same way COLORVAL's are, second it means that any code that rely on
palette indices won't work on truecolor displays at all, as far as I can
understand.
>: 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.
Does it? In GdFindColor(), if TRUECOLOR is defined and the driver returns
a SCREENINFO structure that states that more than 256 colors are available,
it just casts the COLORVAL to PIXELVAL and returns it. So if it is passed
a palette index, you'll get "RGB" values of the type (F_PALINDEX | index),
which certainly won't map to the right color. Or is there something I've
overlooked?
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.
Regards,
Vidar
