nanogui: proposed change to microwindows color values
Subject:
Re: proposed change to microwindows color values
From:
"Bradley D. LaRonde" ####@####.####
Date:
14 Oct 1999 20:39:32 -0000
Message-Id: <01d401bf1683$428fcb30$b8119526@ltc.com>
----- 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
