nanogui: NanoGUI palette model


Previous by date: 30 Sep 1999 16:57:09 -0000 Re: NanoGUI palette model, Bradley D. LaRonde
Next by date: 30 Sep 1999 16:57:09 -0000 Re: NanoGUI palette model, Bradley D. LaRonde
Previous in thread: 30 Sep 1999 16:57:09 -0000 Re: NanoGUI palette model, Bradley D. LaRonde
Next in thread: 30 Sep 1999 16:57:09 -0000 Re: NanoGUI palette model, Bradley D. LaRonde

Subject: RE: NanoGUI palette model
From: Greg Haerr ####@####.####
Date: 30 Sep 1999 16:57:09 -0000
Message-Id: <01BF0B32.1B3C7300.greg@censoft.com>

: > 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.

	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.

: 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.

Greg

Previous by date: 30 Sep 1999 16:57:09 -0000 Re: NanoGUI palette model, Bradley D. LaRonde
Next by date: 30 Sep 1999 16:57:09 -0000 Re: NanoGUI palette model, Bradley D. LaRonde
Previous in thread: 30 Sep 1999 16:57:09 -0000 Re: NanoGUI palette model, Bradley D. LaRonde
Next in thread: 30 Sep 1999 16:57:09 -0000 Re: NanoGUI palette model, Bradley D. LaRonde


Powered by ezmlm-browse 0.20.