[<<] [<] Page 3 of 3 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: NanoGUI palette model
From: "Bradley D. LaRonde" ####@####.#### Date: 30 Sep 1999 19:03:14 -0000 Message-Id: <013901bf0b75$7becd120$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 > : > : 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 [Content type application/octet-stream not shown. Download] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: NanoGUI palette model
From: Greg Haerr ####@####.#### Date: 30 Sep 1999 20:27:55 -0000 Message-Id: <01BF0B4F.968DCAA0.greg@censoft.com> : 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: NanoGUI palette model
From: "Bradley D. LaRonde" ####@####.#### Date: 30 Sep 1999 20:44:58 -0000 Message-Id: <01ff01bf0b83$afaa7b30$b8119526@ltc.com> ----- 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: NanoGUI palette model
From: Alan Cox ####@####.#### Date: 1 Oct 1999 17:59:26 -0000 Message-Id: <E11X6oR-0004ha-00@the-village.bc.nu> > 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: NanoGUI palette model
From: Timo Ketola ####@####.#### Date: 5 Oct 1999 10:06:55 -0000 Message-Id: <37F9CBEC.16BBC430@Epec.fi> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 3 of 3 [>] [>>] |