nanogui: proposed change to microwindows color values


Previous by date: 14 Oct 1999 21:40:53 -0000 Re: proposed change to microwindows color values, Bradley D. LaRonde
Next by date: 14 Oct 1999 21:40:53 -0000 mwin 0.85, Greg Haerr
Previous in thread: 14 Oct 1999 21:40:53 -0000 Re: proposed change to microwindows color values, Bradley D. LaRonde
Next in thread:

Subject: Re: proposed change to microwindows color values
From: "Bradley D. LaRonde" ####@####.####
Date: 14 Oct 1999 21:40:53 -0000
Message-Id: <025c01bf168b$d438f130$b8119526@ltc.com>

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


> How much will the overhead of looking up the RGB->color be for fixed
palette
> : systems - any idea ?
> :
>
> Well, what we do is for loop thru the "fixed" palette doing a longword
compare
> (actually we pull the longword into three r,g,b bytes) for the complete
> palette size.  If an exact match if found, that index is returned,
otherwise
> three multiplies are performed, and if the "distance" is smallest, that
index
> is saved.  The process repeats. If no complete match is found, the
smallest
> index is returned.
>
> The smaller the palette, the quicker the process.  It is worst
> case at 16 colors, since the 256 color palette uses 16 reserved colors
> at the beginning, and standard colors must be in this group.

Oh, right, there are only 16 standard colors and all in the front of the
palette so the extra overhead can only apply to those 16 colors even for
8bpp.

Regards,
Brad


Previous by date: 14 Oct 1999 21:40:53 -0000 Re: proposed change to microwindows color values, Bradley D. LaRonde
Next by date: 14 Oct 1999 21:40:53 -0000 mwin 0.85, Greg Haerr
Previous in thread: 14 Oct 1999 21:40:53 -0000 Re: proposed change to microwindows color values, Bradley D. LaRonde
Next in thread:


Powered by ezmlm-browse 0.20.