nanogui: NanoGUI palette model
Subject:
Re: NanoGUI palette model
From:
"Bradley D. LaRonde" ####@####.####
Date:
30 Sep 1999 13:18:29 -0000
Message-Id: <001301bf0b45$4f0b1ac0$b8119526@ltc.com>
----- Original Message -----
From: Vidar Hokstad ####@####.####
To: Bradley D. LaRonde ####@####.####
Cc: ####@####.####
Sent: Thursday, September 30, 1999 3:53 AM
Subject: Re: NanoGUI palette model
> On Wed, 29 Sep 1999 13:57:24 -0400 you wrote:
> >----- 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.
>
> But the upper levels of Nano-X doesn't know about the frame buffer device,
> and not all drivers will use the frame buffer device, so the info must
> be available from the driver.
Yes, I realized that yesterday and last night.
So, how to fix?
My first instinct is to modify/expand screen interface (scrdev) to contain
this info.
However, even though this info can be made available, for size and speed
reasons it might be better to ignore it (except as an init sanity check),
and just compile in the right driver. That way we don't have to do
if(scrdev.visual == GD_VISUAL_TRUECOLOR) for every find-color, put-pixel,
etc.
What are your thoughts on that?
Regards,
Brad
