nanogui: proposed change to microwindows color values
Subject:
Re: proposed change to microwindows color values
From:
"Bradley D. LaRonde" ####@####.####
Date:
14 Oct 1999 21:10:28 -0000
Message-Id: <020a01bf1687$97007990$b8119526@ltc.com>
----- Original Message -----
From: Greg Haerr ####@####.####
To: 'Bradley D. LaRonde' ####@####.#### Alan Cox ####@####.####
Cc: ####@####.#### ####@####.####
Sent: Thursday, October 14, 1999 4:47 PM
Subject: RE: proposed change to microwindows color values
> : 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.
>
>
> So if we go with the idea that user programs _always_ specify color
> with RGB only, then the overhead remains only on the palette-based
systems,
> and truecolor systems fly. there will always be more overhead on palette
> systems, anyway. BTW, we can still keep the F_PALINDEX bit and
> use it, but leave it to the applications programmer to make sure that the
system
> palette is big enough.
Yeah, there probably isn't that much overhead to be saved by eliminating the
checks for that bit from devdraw.c.
I wonder if we should give applications a way to know what's in the standard
palette.
> Then the only issue remains with the conversion of our internal bitmap
> structure just before displaying the bitmap; that is, a new palette is
created
> that maps the bitmap values to the nearest color system palette indexes
> just before display. If the bitmap's are ID'd (new concept for
microwindows)
> then this palette conversion only has to be done once, and the changed
palette
> will remain valid until the next system palette change.
Good optimization idea.
Regards,
Brad
