nanogui: Thread: NanoGUI palette model

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

: 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

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

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


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

OK, here is the patch.

I got tripped up over the fact that you store RGB as BGR in COLORVAL until I
ran across your *VALUE macros.  I'm curious - why do you store it that way?


Regards,
Brad

: BTW, you pulled this topic off the list - was that intentional?

	No

: 
: Anyway, I'm wondering: since the middle layer is flipped (BGR) to help the
: Microwin layer be directly compatable with Win32 ordering, that means that
: all non-Microwin top layers will have to a) either adopt the bogus window
: BGR ordering, or b) use real RGB and flip it for the middle layer.  Do you
: think maybe it would be better to make Microwin flip so that others don't
: have to?  I know that there really aren't "others", but if more come, RGB
: ordering seems more natural than BGR ordering.
: 
: Here's another way of putting it:  I think it might be more digestible to
: consume "Windows is backwards" than "MicroGDI is backwards" (even though you
: and I both know that it is all relative).
: 
	This is really a very small issue.  There are countless ways
to organize data.  I just chose one way.  

	BTW, it isn't backwards.  Consider the structure defined in device.h:

	typedef struct {
		char r;
		char g;
		char b;
	};

	When this struct is laid down in ram (for instance in a longword)
on a little-endian machine (all intel and mips) then the byte order you get is
exactly the order that you think is backwards.  This allows the palette
entries (RGB values) to be read using an old-fashioned (nonportable) C trick without
calling a function:
	rgbval = (*(unsigned long *)&rgbentry) & 0xFFFFFF;

Greg

----- Original Message -----
From: Greg Haerr ####@####.####
To: 'Bradley D. LaRonde' ####@####.####
Cc: ####@####.####
Sent: Thursday, September 30, 1999 4:25 PM
Subject: RE: NanoGUI palette model


> : Anyway, I'm wondering: since the middle layer is flipped (BGR) to help
the
> : Microwin layer be directly compatable with Win32 ordering, that means
that
> : all non-Microwin top layers will have to a) either adopt the bogus
window
> : BGR ordering, or b) use real RGB and flip it for the middle layer.  Do
you
> : think maybe it would be better to make Microwin flip so that others
don't
> : have to?  I know that there really aren't "others", but if more come,
RGB
> : ordering seems more natural than BGR ordering.
> :
> : Here's another way of putting it:  I think it might be more digestible
to
> : consume "Windows is backwards" than "MicroGDI is backwards" (even though
you
> : and I both know that it is all relative).
> :
> This is really a very small issue.  There are countless ways
> to organize data.  I just chose one way.

I know.  I'm commenting on your choice.  I do think it matters.  Maybe there
is no technical issue, but what about the issues of understandability and
familiarity?


> BTW, it isn't backwards.  Consider the structure defined in device.h:
>
> typedef struct {
> char r;
> char g;
> char b;
> };
>
> When this struct is laid down in ram (for instance in a longword)
> on a little-endian machine (all intel and mips) then the byte order you
get is
> exactly the order that you think is backwards.  This allows the palette
> entries (RGB values) to be read using an old-fashioned (nonportable) C
trick without
> calling a function:
> rgbval = (*(unsigned long *)&rgbentry) & 0xFFFFFF;

I saw that struct.  That's what throws things off.  Why even define a struct
of three chars?

The thing is, what is a COLORVAL?  It is an unsigned long (ul32 might be
better put), but is it 0x00rrggbb or 0x00bbggrr?  I'm more comfortable with
and would probably assume the first (i.e. HTML does it #rrggbb).

By declaring the struct, you make endianness an issue.  I don't think it
needs to be.

Regards,
Brad

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

There is a subtle and important semantic you want to keep if you want stuff
to continue to work well for a long time.

Top level calls driver. Driver calls midlevel as a library.

Doing it that way means a smart driver or a plain weird one can opt out of
midlevel policy.

Alan

Bradley,

I tried to send you a reply some time ago but this time I didn't CC to the
list. I didn't get any answer from you and we had a minor problem with our
mailserver so I try once more through this list. My apologies to others not
concerned.

"Bradley D. LaRonde" wrote:

> ----- Original Message -----
> From: Timo Ketola ####@####.####
> To: Bradley D. LaRonde ####@####.####
> Cc: ####@####.####
> Sent: Tuesday, September 28, 1999 11:16 AM
> Subject: Re: NanoGUI palette model
>
> > It's our own design. It features AMD Elan SC400 (486 class) CPU, 8M dram,
> 8M
> > flash and 2 CAN Bus + 2 RS232/485 + PC/XT keyboard + mouse interfaces.
>
> Thx.  What is the display like?  Also, how much will it cost?

The display is 320x240 monochrome STN LCD. It looks the same as our other
product of which you can find a picture in http://www.epec.fi/display.htm. The
differences are that that one is bigger and have color display and one more
front panel button. About the price I can give only very rough estimate of
1000 euros. If you are still interested I could send you an actual jpg of the
display and ask our salesman to send you a quote.

--

Timo