nanogui: Thread: NanoGUI palette model

On Wed, 29 Sep 1999 08:26:31 -0400 you wrote:
>----- 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. 

As far as I can see from Gregs code there are two palettes: The driver
palette, which is static, and the system palette, which can be modified.
The system palette maps 8 bit indexes into the system palette into
whatever is the closest matching PIXELVAL, which may be the RGB value,
or an index into the drivers palette.
 
>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. 

It's often convenient to use palettes anyway. For instance with pixmaps
which actually have only a few colors. And forcing the drivers to do
color conversion every time isn't very efficient performance wise.
 
>As for the differences in mapping between RGB bit layouts, again, the driver 
>can do the mapping, no? 

They can, but it's not efficient. The point of mapping it in GdFindColor
would be that you can build up a cache of PIXELVAL's corresponding to the
appropriate color, and not have to convert for each and every operation.
Thus, IMHO, GdFindColor() should return the most efficient way of
representing the color for the hardware driver, not something that will
have to be converted yet another time.

Regards,
Vidar

: >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.
: 
	That's not true.  MicroWindows does set hw palettes, thru the setpalette
screen driver entry point.  Basically, MicroWindows is linked with one of the devpalX.c
files, which are pre-built palettes for 2, 8, 16 or 256 colors.  The first thing
that happens is the MicroWindows sets the hardware palette for the first X entries
from this table.  The driver is responsible for converting RGB entries to PIXELVALs.
Normally, this is extremely simple, as the palette index is the PIXELVAL and the
contents are the COLORVAL.  
	During operation, MicroWindows may "extend" the palette beyond the initial
range for display of large color images.  In this case, MicroWindows calls the device
driver setpalette function again.

	Microwindows always calls the setpalette function, there is no need for a
getpalette function, instead, the initial devpalX.c handles this.

Greg

: 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 say just put the code in GdFindColor for now.  This function is
responsible for converting a COLORVAL to a PIXELVAL.  It would be fairly
easy to separate the 24/32 bit value to 15/16/24/32 bits.  I started with the
#ifdef TRUECOLOR, but cant' test anything cause I can't get the damned
framebuffer to run 32 bits...  (And we don't yet have a real-mode 640x480x256
driver)


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

	I agree.  #defining TRUECOLOR isn't implemented, really, I just
stuck it in to point to where the work is needed.  Let's implement as you
suggest, we can't assume that COLORVAL==PIXELVAL.  I suggest
adding another entry in the scrdev structure that indicates the way that
the hardware PIXELVALs are packed, and the devdraw.c code can pack
them according to the enum: PACKED15, PACKED16, PACKED24, PACKED32,
or any other crazy format.


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

	This needs fixing as stated above.

 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?

	You're right.  Ultimately, I suggest *not* using palette indexes in
application programs.  I only added it so that you _can_ have it if you really
want it, _and_ know what hw you're running on.  Normally, all apps, including
widgets, should use RGB schemes only.  This means that we should have
a separate color definition file for BLACK, BLUE, WHITE, etc.  --OR-- we
always use F_PALINDEX colors by reading their RGB entry from the linked
in devpalX.c, and then use the above algorithm.


: 
: 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.
: 
	OK.  - I agree.

Greg

: 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

----- Original Message -----
From: Greg Haerr ####@####.####
To: 'Vidar Hokstad' ####@####.####
Cc: ####@####.####
Sent: Wednesday, September 29, 1999 1:24 PM
Subject: RE: NanoGUI palette model


> I agree.  #defining TRUECOLOR isn't implemented, really, I just
> stuck it in to point to where the work is needed.  Let's implement as you
> suggest, we can't assume that COLORVAL==PIXELVAL.  I suggest
> adding another entry in the scrdev structure that indicates the way that
> the hardware PIXELVALs are packed, and the devdraw.c code can pack
> them according to the enum: PACKED15, PACKED16, PACKED24, PACKED32,
> or any other crazy format.

That info is already available from a frame buffer device.


> You're right.  Ultimately, I suggest *not* using palette indexes in
> application programs.  I only added it so that you _can_ have it if you
really
> want it, _and_ know what hw you're running on.  Normally, all apps,
including
> widgets, should use RGB schemes only.  This means that we should have
> a separate color definition file for BLACK, BLUE, WHITE, etc.  --OR-- we
> always use F_PALINDEX colors by reading their RGB entry from the linked
> in devpalX.c, and then use the above algorithm.

I think palettes are an option you can't always count on.

I much prefer the idea that applications and widgets always use RGB, with
standard 8 or 16 colors defined BLACK, BLUE, WHITE, etc. guaranteed to be
available if physically possible.


> : 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.
> :
> OK.  - I agree.

This make senses to me too, although I hope ppl don't need to use it.


Regards,
Brad

: As far as I can see from Gregs code there are two palettes: The driver
: palette, which is static, and the system palette, which can be modified.
: The system palette maps 8 bit indexes into the system palette into
: whatever is the closest matching PIXELVAL, which may be the RGB value,
: or an index into the drivers palette.

	Almost, Vidar.  (You're doing great, though)  There's really only
one palette, the one linked in devpalX.c.  This palette starts out static,
with a "bar" indicating the "system" colors.  Below the bar are system
colors, above, user-defineable.  The bar starts at approximately 24.  (FIRSTUSERPALETTEENTRY)
When the bar increments, the device driver is called to set a new system
palette from the linked in palette.  Every time this raises, the hw
palette is modified, until there's no more entries.  The user program can
reset the palette (user entries) with the GdResetPalette() call.  The
GdDrawImage call will merge/build palette entries according to
an internal algorithm.

: 
: It's often convenient to use palettes anyway. For instance with pixmaps
: which actually have only a few colors. And forcing the drivers to do
: color conversion every time isn't very efficient performance wise.
:  

	I agree.


: >As for the differences in mapping between RGB bit layouts, again, the driver 
: >can do the mapping, no? 
: 
: They can, but it's not efficient. The point of mapping it in GdFindColor
: would be that you can build up a cache of PIXELVAL's corresponding to the
: appropriate color, and not have to convert for each and every operation.
: Thus, IMHO, GdFindColor() should return the most efficient way of
: representing the color for the hardware driver, not something that will
: have to be converted yet another time.
: 
	Exactly.  This is also extremely important when we move to 
bitblt's which are PIXELVAL->PIXELVAL moves.  The nano-X ReadArea8()
function relies on this.

Greg

 
: I think palettes are an option you can't always count on.


	Yep.  The driver model allows for this case.

: 
: I much prefer the idea that applications and widgets always use RGB, with
: standard 8 or 16 colors defined BLACK, BLUE, WHITE, etc. guaranteed to be
: available if physically possible.
: 
	Yep - that's what I'd like to see (and have already implemented) as well.

Greg

On Wed, 29 Sep 1999 13:57:24 -0400 you wrote:
>----- Original Message ----- 
>From: Greg Haerr ####@####.#### 
>To: 'Vidar Hokstad' ####@####.#### 
>Cc: ####@####.#### 
>Sent: Wednesday, September 29, 1999 1:24 PM 
>Subject: RE: NanoGUI palette model 
> 
> 
>> I agree.  #defining TRUECOLOR isn't implemented, really, I just 
>> stuck it in to point to where the work is needed.  Let's implement as you 
>> suggest, we can't assume that COLORVAL==PIXELVAL.  I suggest 
>> adding another entry in the scrdev structure that indicates the way that 
>> the hardware PIXELVALs are packed, and the devdraw.c code can pack 
>> them according to the enum: PACKED15, PACKED16, PACKED24, PACKED32, 
>> or any other crazy format. 
> 
>That info is already available from a frame buffer device. 

But the upper levels of Nano-X doesn't know about the frame buffer device,
and not all drivers will use the frame buffer device, so the info must
be available from the driver.

Vidar.

----- Original Message -----
From: Vidar Hokstad ####@####.####
To: Bradley D. LaRonde ####@####.####
Cc: ####@####.####
Sent: Thursday, September 30, 1999 3:53 AM
Subject: Re: NanoGUI palette model


> On Wed, 29 Sep 1999 13:57:24 -0400 you wrote:
> >----- Original Message -----
> >From: Greg Haerr ####@####.####
> >To: 'Vidar Hokstad' ####@####.####
> >Cc: ####@####.####
> >Sent: Wednesday, September 29, 1999 1:24 PM
> >Subject: RE: NanoGUI palette model
> >
> >
> >> I agree.  #defining TRUECOLOR isn't implemented, really, I just
> >> stuck it in to point to where the work is needed.  Let's implement as
you
> >> suggest, we can't assume that COLORVAL==PIXELVAL.  I suggest
> >> adding another entry in the scrdev structure that indicates the way
that
> >> the hardware PIXELVALs are packed, and the devdraw.c code can pack
> >> them according to the enum: PACKED15, PACKED16, PACKED24, PACKED32,
> >> or any other crazy format.
> >
> >That info is already available from a frame buffer device.
>
> But the upper levels of Nano-X doesn't know about the frame buffer device,
> and not all drivers will use the frame buffer device, so the info must
> be available from the driver.

Yes, I realized that yesterday and last night.

So, how to fix?

My first instinct is to modify/expand screen interface (scrdev) to contain
this info.

However, even though this info can be made available, for size and speed
reasons it might be better to ignore it (except as an init sanity check),
and just compile in the right driver.  That way we don't have to do
if(scrdev.visual == GD_VISUAL_TRUECOLOR) for every find-color, put-pixel,
etc.

What are your thoughts on that?


Regards,
Brad

: > But the upper levels of Nano-X doesn't know about the frame buffer device,
: > and not all drivers will use the frame buffer device, so the info must
: > be available from the driver.

	Definitely.  I was suggesting the following.  The SCREENDEVICE
struct is extended with another member, pixelformat, that is an enumerated
type.  Since we're trying to keep this small, we add new enumerated types
when we add hardware that requires them.  The suggested values, PACKED15,
PACKED16, PACKED24 and PACKED32 basically indicate a standard algorithm
that GdFindColor() uses to convert an RGB COLORVAL value into a PIXELVAL
value, without using the palette table.  Another value, PALETTE, would be used
to indicate the hardware is palette-driven, and to use the palette algorithm
currently running.
	Brad can add a PACKED8 value, and the code in GdFindColor() to
unpack this particular value.  Others can add peculiar code for peculiar
hardware at their leisure.

	Remember that when SCREENDEVICE is modified, _all_ screen
drivers need to be modified, ELKS, DOS, etc.  That's why it's a good
idea to have a discussion when changing the device driver interface.

	If either/both of you get your hardware running, I'd be glad
to integrate it in a fashion that will be acceptable, integrated into the standard
release.

: However, even though this info can be made available, for size and speed
: reasons it might be better to ignore it (except as an init sanity check),
: and just compile in the right driver.  That way we don't have to do
: if(scrdev.visual == GD_VISUAL_TRUECOLOR) for every find-color, put-pixel,
: etc.
: 
	User programs specifying RGB has a certain amount of overhead,
and that includes the conversion for possibly every pixel.  This is certainly the
method used in bitmap drawing.  For line drawing, and other highly optimizable routines,
the static global gr_foreground contains the color specified for the entire line,
and the lookup is done just once.  Actually, most of the mid-level draw routines
use a foreground or background PIXELVAL that was specified and converted
only once in a separate call.

Greg