nanogui: proposed change to microwindows color values
Subject:
proposed change to microwindows color values
From:
Greg Haerr ####@####.####
Date:
14 Oct 1999 20:19:31 -0000
Message-Id: <01BF164E.DB78F220.greg@censoft.com>
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
