Subject:
Re: NanoGUI palette model
From:
"Bradley D. LaRonde" ####@####.####
Date:
30 Sep 1999 17:10:58 -0000
Message-Id: <00bc01bf0b65$cb9f2430$b8119526@ltc.com>
----- Original Message -----
From: Greg Haerr ####@####.####
To: 'Bradley D. LaRonde' ####@####.#### Vidar Hokstad
####@####.####
Cc: ####@####.####
Sent: Thursday, September 30, 1999 12:54 PM
Subject: RE: NanoGUI palette model
> : > 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.
>
> Definitely. I was suggesting the following. The SCREENDEVICE
> struct is extended with another member, pixelformat, that is an enumerated
> type. Since we're trying to keep this small, we add new enumerated types
> when we add hardware that requires them. The suggested values, PACKED15,
> PACKED16, PACKED24 and PACKED32 basically indicate a standard algorithm
> that GdFindColor() uses to convert an RGB COLORVAL value into a PIXELVAL
> value, without using the palette table. Another value, PALETTE, would be
used
> to indicate the hardware is palette-driven, and to use the palette
algorithm
> currently running.
> Brad can add a PACKED8 value, and the code in GdFindColor() to
> unpack this particular value. Others can add peculiar code for peculiar
> hardware at their leisure.
Hmmm... enumeration seems like a good idea. I'm think that it may be better
than frame buffer bit fields thing. It might mean several separate
converter functions, but I think they will be small, inline, and fast
compared to a generic converter algorithm based on bit fields. Does that
sound right?
What about having the driver provide the conversion function? Bad idea?
> Remember that when SCREENDEVICE is modified, _all_ screen
> drivers need to be modified, ELKS, DOS, etc. That's why it's a good
> idea to have a discussion when changing the device driver interface.
>
> If either/both of you get your hardware running, I'd be glad
> to integrate it in a fashion that will be acceptable, integrated into the
standard
> release.
Who will add this new SCREENDEVICE field (member), and when?
> : 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.
> :
> User programs specifying RGB has a certain amount of overhead,
> and that includes the conversion for possibly every pixel. This is
certainly the
> method used in bitmap drawing. For line drawing, and other highly
optimizable routines,
> the static global gr_foreground contains the color specified for the
entire line,
> and the lookup is done just once. Actually, most of the mid-level draw
routines
> use a foreground or background PIXELVAL that was specified and converted
> only once in a separate call.
The problem is now we potentially have a big case statement that has to be
evaluated for *every* conversion. Is this serious?
Regards,
Brad
