nanogui: proposed change to microwindows color values
Subject:
Re: proposed change to microwindows color values
From:
"Bradley D. LaRonde" ####@####.####
Date:
14 Oct 1999 21:39:03 -0000
Message-Id: <025001bf168b$93320fa0$b8119526@ltc.com>
----- Original Message -----
From: Alan Cox ####@####.####
To: ####@####.####
Cc: ####@####.#### ####@####.#### ####@####.####
####@####.####
Sent: Thursday, October 14, 1999 5:17 PM
Subject: Re: proposed change to microwindows color values
> > : 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?
>
> How much will the overhead of looking up the RGB->color be for fixed
palette
> systems - any iea ?
See GdFindNearestColor. It loops through the system palette doing nine
multiples and two adds and a comparison. Not too bad if the system palette
is only 4 entries long. In fact, we might be able to wildly optimize it in
the 2bpp case - something like look at the green level first and factor in
the others if necessary. I think the only cases are mono (1bpp), four-color
grey (2bpp), sixteen-color (4bpp), and 256-color (8bpp). It could get ugly
in the 256-color case, but still, for things like fills you only do it once
for many many pixels. It's bitmaps that suffer the most, and keeping the
conversion handy might yield very acceptable performance.
Regards,
Brad
