nanogui: NanoGUI palette model
Subject:
RE: NanoGUI palette model
From:
Greg Haerr ####@####.####
Date:
30 Sep 1999 17:23:29 -0000
Message-Id: <01BF0B35.D1AE8170.greg@censoft.com>
: 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.
:
: Who will add this new SCREENDEVICE field (member), and when?
I'll do it. Get your hardware working, and send me the patch.
Or you can do it, but you ought to modify all the drivers. I'd be happy to do it,
after you send me a patch for your particular hardware.
: The problem is now we potentially have a big case statement that has to be
: evaluated for *every* conversion. Is this serious?
No.
Greg
