nanogui: NanoGUI palette model
Subject:
Re: NanoGUI palette model
From:
"Bradley D. LaRonde" ####@####.####
Date:
30 Sep 1999 17:29:48 -0000
Message-Id: <00d001bf0b68$6d80dfd0$b8119526@ltc.com>
----- Original Message -----
From: Greg Haerr ####@####.####
To: 'Bradley D. LaRonde' ####@####.#### Vidar Hokstad
####@####.####
Cc: ####@####.####
Sent: Thursday, September 30, 1999 1:20 PM
Subject: RE: NanoGUI palette model
> : 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?
> :
> It'll be a switch statement in GdFindColor(). Think small.
>
> : What about having the driver provide the conversion function? Bad idea?
>
> I don't want drivers with a million entry points. Not yet. They'll
> come, but I'm trying to hold back on the urge to make this big. It's also
> slower, and most cases can be handled at mid-level. After all, we're
talking
> about pretty simple code here. Another way of thinking of it is I'm trying
> to keep the driver-duplicated code to a minimum, that's what the midlevel
is
> for.
OK, I understand about keeping drivers small. Just wanted to toss out the
idea in case there was a compelling technical argument.
What about this - put #ifdefs around each part of the switch, so we can only
compile in the code we need, making the code smaller and faster since it has
less switching to do.
Regards,
Brad
