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