nanogui: Thread: proposed change to microwindows color values

Vidar/Brad,
	I wanted to document a change I'm planning for the color
support for the nanox and microwindows engines.  The changes
doesn't have any implications for user programs or widget sets,
but I thought I'd get everyone's opinion.

	Basically, currently microwindows assumes that the system
will always have 16 colors available for drawing.  This assumption proved
false with the port to 2bpp machines like the MIPS based Everex Freestyle.
Because of this assumption, I previously added color constants in device.h
(WHITE, RED, LTGRAY....) that use the F_PALINDEX flag to allow
microwindows to get the color _damn_fast_ without the need for
using the distance-cubed method of finding a nearest color.  Unfortunately,
when microwindows is compiled with different devpalX.c files, this assumption
can't work because the palette will get over-indexed.

	So a proposal is to move to color constants that are always RGB,
and always compute the value regardless whenever a draw is needed.  Currently,
the only potential problem area is that of fast bitmap drawing, since the overhead
for fillrect etc is minimal.  Also, the idea of compiling in separate devpalX.c
files is not going to work, since now microwindows can run on most any
framebuffer device, any size palette, and many truecolor modes. 

Comments?

Greg

> will always have 16 colors available for drawing.  This assumption proved
> false with the port to 2bpp machines like the MIPS based Everex Freestyle.
> Because of this assumption, I previously added color constants in device.h
> (WHITE, RED, LTGRAY....) that use the F_PALINDEX flag to allow
> microwindows to get the color _damn_fast_ without the need for
> using the distance-cubed method of finding a nearest color.  Unfortunately,
> when microwindows is compiled with different devpalX.c files, this assumption
> can't work because the palette will get over-indexed.


How about providing an array of 'best effort' for the base colours, black white
dark grey and light grey ? The driver could set these up at setup time, and
the application can do some kind of

	GetSystemColours(array, len)

to get them. 

----- Original Message -----
From: Greg Haerr ####@####.####
To: 'Vidar Hokstad' ####@####.#### 'Bradley D. LaRonde'
####@####.####
Cc: ####@####.####
Sent: Thursday, October 14, 1999 4:17 PM
Subject: proposed change to microwindows color values


> Vidar/Brad,
> I wanted to document a change I'm planning for the color
> support for the nanox and microwindows engines.  The changes
> doesn't have any implications for user programs or widget sets,
> but I thought I'd get everyone's opinion.
>
> Basically, currently microwindows assumes that the system
> will always have 16 colors available for drawing.  This assumption proved
> false with the port to 2bpp machines like the MIPS based Everex Freestyle.
> Because of this assumption, I previously added color constants in device.h
> (WHITE, RED, LTGRAY....) that use the F_PALINDEX flag to allow
> microwindows to get the color _damn_fast_ without the need for
> using the distance-cubed method of finding a nearest color.
Unfortunately,
> when microwindows is compiled with different devpalX.c files, this
assumption
> can't work because the palette will get over-indexed.
>
> So a proposal is to move to color constants that are always RGB,
> and always compute the value regardless whenever a draw is needed.
Currently,
> the only potential problem area is that of fast bitmap drawing, since the
overhead
> for fillrect etc is minimal.  Also, the idea of compiling in separate
devpalX.c
> files is not going to work, since now microwindows can run on most any
> framebuffer device, any size palette, and many truecolor modes.
>
> Comments?

I made the same (incorrect) 16-color assumption that you did, not thinking
about those very limited greyscale screens.  I think you've hit the nail
right on the head as far as the solution goes.  And yes, the added overhead
for doing it this way is very small in most cases.  However, we are already
doing a conversion palette for bitmaps, so I'm not sure it will even add
overhead there.  Maybe it will even end up slightly reducing the total
overhead as we might be able to do less checking and branching on the
F_PALINDEX bit.

Regards,
Brad

----- Original Message -----
From: Alan Cox ####@####.####
To: ####@####.####
Cc: ####@####.#### ####@####.#### ####@####.####
Sent: Thursday, October 14, 1999 4:14 PM
Subject: Re: proposed change to microwindows color values


> > will always have 16 colors available for drawing.  This assumption
proved
> > false with the port to 2bpp machines like the MIPS based Everex
Freestyle.
> > Because of this assumption, I previously added color constants in
device.h
> > (WHITE, RED, LTGRAY....) that use the F_PALINDEX flag to allow
> > microwindows to get the color _damn_fast_ without the need for
> > using the distance-cubed method of finding a nearest color.
Unfortunately,
> > when microwindows is compiled with different devpalX.c files, this
assumption
> > can't work because the palette will get over-indexed.
>
>
> How about providing an array of 'best effort' for the base colours, black
white
> dark grey and light grey ? The driver could set these up at setup time,
and
> the application can do some kind of
>
> GetSystemColours(array, len)
>
> to get them.

That ends up adding a lookup everywhere that system colors are used, which
kinda defeats (though not completely) the idea of a hardware palette index
in the first place.

However, along the same lines maybe we can do some caching in the
RGB-to-hardware conversion for non-truecolor displays, although I don't know
that it would offer much overall improvement.

Regards,
Brad

: How about providing an array of 'best effort' for the base colours, black white
: dark grey and light grey ? The driver could set these up at setup time,

Alan,
	Your idea is similar to something we've discussed.  One idea
was that the "default" be laid out in a way such that it is downward compatible
from 16 -> 8 -> 4 -> 2 color.  So it might be laid out like:

	BLACK		; valid for 2,4,16
	WHITE		; valid for 2, 4, 16
	LTGRAY	; valid for 4, 16
	GRAY		; valid for 4, 16
	RED		; valid for 16
	etc

The only problem is this still won't work for static_pseudocolor systems
that might have a different layout, as well as requiring that the system
be ported to have a writable palette before _any_ screen driver will work,
which is a pain, since most operating systems don't store their values in 
this order.

	The other answer was to statically build a reverse palette lookup
table, based on the system palette, read only or not.  but then
alot of the gain of the F_PALINDEX bit is lost, since we're looking up
two tables to get anywhere anyway...

Greg

: That ends up adding a lookup everywhere that system colors are used, which
: kinda defeats (though not completely) the idea of a hardware palette index
: in the first place.


So if we go with the idea that user programs _always_ specify color
with RGB only, then the overhead remains only on the palette-based systems,
and truecolor systems fly.  there will always be more overhead on palette
systems, anyway.  BTW, we can still keep the F_PALINDEX bit and
use it, but leave it to the applications programmer to make sure that the system
palette is big enough.

Then the only issue remains with the conversion of our internal bitmap
structure just before displaying the bitmap; that is, a new palette is created
that maps the bitmap values to the nearest color system palette indexes
just before display.  If the bitmap's are ID'd (new concept for microwindows)
then this palette conversion only has to be done once, and the changed palette
will remain valid until the next system palette change.

Greg

> The only problem is this still won't work for static_pseudocolor systems

It does because its an indirection.

> that might have a different layout, as well as requiring that the system

Its not a colour table, its a table of colour numbers - indexes into the main
table. For example it might be that white is colour 0 on an LCD and
STDCOLOR_BLACK is 1. If so then colors[STDCOLOR_BLACK]= 0.

On a mono display I guess red/blue/green map t black and yellow/... to white

No problems

----- Original Message -----
From: Greg Haerr ####@####.####
To: 'Bradley D. LaRonde' ####@####.#### Alan Cox ####@####.####
Cc: ####@####.#### ####@####.####
Sent: Thursday, October 14, 1999 4:47 PM
Subject: RE: proposed change to microwindows color values


> : That ends up adding a lookup everywhere that system colors are used,
which
> : kinda defeats (though not completely) the idea of a hardware palette
index
> : in the first place.
>
>
> So if we go with the idea that user programs _always_ specify color
> with RGB only, then the overhead remains only on the palette-based
systems,
> and truecolor systems fly.  there will always be more overhead on palette
> systems, anyway.  BTW, we can still keep the F_PALINDEX bit and
> use it, but leave it to the applications programmer to make sure that the
system
> palette is big enough.

Yeah, there probably isn't that much overhead to be saved by eliminating the
checks for that bit from devdraw.c.

I wonder if we should give applications a way to know what's in the standard
palette.


> Then the only issue remains with the conversion of our internal bitmap
> structure just before displaying the bitmap; that is, a new palette is
created
> that maps the bitmap values to the nearest color system palette indexes
> just before display.  If the bitmap's are ID'd (new concept for
microwindows)
> then this palette conversion only has to be done once, and the changed
palette
> will remain valid until the next system palette change.

Good optimization idea.


Regards,
Brad

: Its not a colour table, its a table of colour numbers - indexes into the main
: table. For example it might be that white is colour 0 on an LCD and
: STDCOLOR_BLACK is 1. If so then colors[STDCOLOR_BLACK]= 0.
: 
	Yes.  That's what I was trying to say.  So - should we
build this table from scratch, or just link in one that will work?
Also, do you believe we should do this just to keep "simple" palette
indices working, or move to RGB for user programs?


: On a mono display I guess red/blue/green map t black and yellow/... to white
: 
	Yes, or at least the lobright to black and hibright to white.

----- Original Message -----
From: Alan Cox ####@####.####
To: ####@####.####
Cc: ####@####.#### ####@####.#### ####@####.####
####@####.####
Sent: Thursday, October 14, 1999 4:55 PM
Subject: Re: proposed change to microwindows color values


> > The only problem is this still won't work for static_pseudocolor systems
>
> It does because its an indirection.

I thought about this.  The thing is, why add the indirection to every call,
especially if we can find a way to optimize (cache maybe) the dist-cubed
thing for 4bpp?

When it comes down to it, any overhead from the indirection or dist-cubed
whether optimized or not is probably too small to notice for the most part
anyway, so adding the indirection might just compilcate things for no real
gain.

Regards,
Brad