nanogui: NanoGUI palette model
Subject:
Re: NanoGUI palette model
From:
"Bradley D. LaRonde" ####@####.####
Date:
29 Sep 1999 18:04:43 -0000
Message-Id: <005301bf0aa4$15cb1bd0$b8119526@ltc.com>
----- Original Message -----
From: Greg Haerr ####@####.####
To: 'Vidar Hokstad' ####@####.####
Cc: ####@####.####
Sent: Wednesday, September 29, 1999 1:24 PM
Subject: RE: NanoGUI palette model
> I agree. #defining TRUECOLOR isn't implemented, really, I just
> stuck it in to point to where the work is needed. Let's implement as you
> suggest, we can't assume that COLORVAL==PIXELVAL. I suggest
> adding another entry in the scrdev structure that indicates the way that
> the hardware PIXELVALs are packed, and the devdraw.c code can pack
> them according to the enum: PACKED15, PACKED16, PACKED24, PACKED32,
> or any other crazy format.
That info is already available from a frame buffer device.
> You're right. Ultimately, I suggest *not* using palette indexes in
> application programs. I only added it so that you _can_ have it if you
really
> want it, _and_ know what hw you're running on. Normally, all apps,
including
> widgets, should use RGB schemes only. This means that we should have
> a separate color definition file for BLACK, BLUE, WHITE, etc. --OR-- we
> always use F_PALINDEX colors by reading their RGB entry from the linked
> in devpalX.c, and then use the above algorithm.
I think palettes are an option you can't always count on.
I much prefer the idea that applications and widgets always use RGB, with
standard 8 or 16 colors defined BLACK, BLUE, WHITE, etc. guaranteed to be
available if physically possible.
> : What I'm suggesting is only that if TRUECOLOR is defined that we get the
> : RGB value from the palette if F_PALINDEX is set, so that palettes
(including
> : user defined) work on truecolor displays too.
> :
> OK. - I agree.
This make senses to me too, although I hope ppl don't need to use it.
Regards,
Brad
