nanogui: Thread: NanoGUI palette model

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

----- Original Message -----
From: Vidar Hokstad ####@####.####
To: ####@####.####
Cc: ####@####.#### ####@####.####
Sent: Tuesday, September 28, 1999 7:34 AM
Subject: NanoGUI palette model


> - If we're drawing on a true type (I assume including 15,16,24 and 32 bit
>    displays?

Please assume 8bpp truecolor also - I need this for the Clio (it's an awful
visual mode but I'm stuck with it).

Regards,
Brad

"Bradley D. LaRonde" wrote:

> ----- Original Message -----
> From: Vidar Hokstad ####@####.####
> To: ####@####.####
> Cc: ####@####.#### ####@####.####
> Sent: Tuesday, September 28, 1999 7:34 AM
> Subject: NanoGUI palette model
>
> > - If we're drawing on a true type (I assume including 15,16,24 and 32 bit
> >    displays?
>
> Please assume 8bpp truecolor also - I need this for the Clio (it's an awful
> visual mode but I'm stuck with it).
>

Please, add also 4bpp directcolor (16 level gray scale) into the soup. I have
such a hardware (320x240 lcd) and I'm dreaming on using linux and NanoGUI with
it. Linux frame buffer is working already.

--

Timo

----- Original Message -----
From: Timo Ketola ####@####.####
To: <unlisted-recipients:; (no To-header on input)>
Cc: ####@####.####
Sent: Tuesday, September 28, 1999 10:44 AM
Subject: Re: NanoGUI palette model


> Please, add also 4bpp directcolor (16 level gray scale) into the soup. I
have
> such a hardware (320x240 lcd) and I'm dreaming on using linux and NanoGUI
with
> it. Linux frame buffer is working already.

What hardware is this?  Are you porting linux to it?

Regards,
Brad

"Bradley D. LaRonde" wrote:

> ----- Original Message -----
> From: Timo Ketola ####@####.####
> To: <unlisted-recipients:; (no To-header on input)>
> Cc: ####@####.####
> Sent: Tuesday, September 28, 1999 10:44 AM
> Subject: Re: NanoGUI palette model
>
> > Please, add also 4bpp directcolor (16 level gray scale) into the soup. I
> have
> > such a hardware (320x240 lcd) and I'm dreaming on using linux and NanoGUI
> with
> > it. Linux frame buffer is working already.
>
> What hardware is this?  Are you porting linux to it?
>
> Regards,
> Brad

It's our own design. It features AMD Elan SC400 (486 class) CPU, 8M dram, 8M
flash and 2 CAN Bus + 2 RS232/485 + PC/XT keyboard + mouse interfaces.
Actually I have already ported linux to it. It wasn't very difficult even
though it has no bios. I also have ported one of our applications to it
(normally run on bare hardware). We are not yet using the linux in production
but it may be near. The transition could be immediate if we only had good
graphics development suite for linux on this kind of hardware P-)

--

Timo

----- Original Message -----
From: Timo Ketola ####@####.####
To: Bradley D. LaRonde ####@####.####
Cc: ####@####.####
Sent: Tuesday, September 28, 1999 11:16 AM
Subject: Re: NanoGUI palette model


> It's our own design. It features AMD Elan SC400 (486 class) CPU, 8M dram,
8M
> flash and 2 CAN Bus + 2 RS232/485 + PC/XT keyboard + mouse interfaces.

Thx.  What is the display like?  Also, how much will it cost?

Regards,
Brad

: 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

On Tue, 28 Sep 1999 17:44:06 +0300 you wrote:
>"Bradley D. LaRonde" wrote: 
> 
>> ----- Original Message ----- 
>> From: Vidar Hokstad ####@####.#### 
>> To: ####@####.#### 
>> Cc: ####@####.#### ####@####.#### 
>> Sent: Tuesday, September 28, 1999 7:34 AM 
>> Subject: NanoGUI palette model 
>> 
>> > - If we're drawing on a true type (I assume including 15,16,24 and 32 bit 
>> >    displays? 
>> 
>> Please assume 8bpp truecolor also - I need this for the Clio (it's an awful 
>> visual mode but I'm stuck with it). 
>> 
> 
>Please, add also 4bpp directcolor (16 level gray scale) into the soup. I have 
>such a hardware (320x240 lcd) and I'm dreaming on using linux and NanoGUI 
>with 
>it. Linux frame buffer is working already. 

That can easily be handled. The palette code in Microwindows doesn't attempt
to set any hardware palette, but just maps the palette the driver presents
to any palette user attempts to set. In this case the hardware driver thus
will only present a 16 level gray scale palette.

Vidar Hokstad
Screen Media AS

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

----- 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.

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.

As for the differences in mapping between RGB bit layouts, again, the driver
can do the mapping, no?

Regards,
Brad