[<<] [<] Page 1 of 3 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
NanoGUI palette model
From: "Vidar Hokstad" ####@####.#### Date: 28 Sep 1999 11:39:19 -0000 Message-Id: <19990928113422.22128.qmail@mail.relight.com> Hi, I've started looking at whats required to combine the NanoGUI and Microwindows drawing code (screen/common.c in Nano-X 0.5pre3 and devdraw.c in Microwindows 0.83), and most of the differences are related to the changed palette model. As far as I can see, the palette handling in MicroWindows is roughly like this (Greg, correct me if I'm wrong, please...), some of which is shared with Nano-X 0.5pre3: - All drawing is based on PIXELVAL, which is an opaque representation of color on whatever screen device you're operating on. - When setting drawing color etc., you user COLORVAL's. COLORVAL is an at least 32 bit integer. - If we're drawing on a true type (I assume including 15,16,24 and 32 bit displays? But I'm not sure if the code does any transformations, and it seems like the code expects COLORVAL to hold a 24 bit R,G,B value for truetype displays), then COLORVAL == PIXELVAL. We might want to differentiate between different types of truetype displays, and convert COLORVAL to the appropriate type. - If we're drawing on a palette based display, all values above F_PALINDEX is considered to be indexes into a palette. If not, GdFindNearestColor() is called. - GdFindNearestColor() approximates the RGB value given, to a value in the palette. - It has calls to merge palettes from for instance a color pixmap with the system palette (which in truecolor would just be the same as the original), to prepare for drawing a pixmap etc. I suggest that we go for this palette model, with a couple of modifications, and I volunteer to reintegrate this palette code into Nano-X 0.5pre3, so that it and Microwindows shares the same palette code. My suggested changes/concerns are these: - As mentioned above, it might be worth converting from a single RGB representation in GdFindColor(), to the hardware specific one. On the other hand this might also be done in the driver. But especially with regard to merging palettes, I'd expect that having the returned palette be a set of hardware specific values would be most efficient. Comments? - I'd like to treat truecolor the same as palette based systems with regards to having an indexed palette. Since F_PALINDEX is defined to be larger than any 24 bit RGB value, it's only a couple of lines. That means that programs should work the same on both truecolor and palette based systems: They either request a PIXELVAL corresponding to a RGB value or a palette index, and the only difference is that for truecolor displays the palette is software only. Regards, Vidar Hokstad Screen Media AS | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: NanoGUI palette model
From: "Bradley D. LaRonde" ####@####.#### Date: 28 Sep 1999 14:03:28 -0000 Message-Id: <009801bf09b9$3a81d450$b8119526@ltc.com> ----- Original Message ----- From: Vidar Hokstad ####@####.#### To: ####@####.#### Cc: ####@####.#### ####@####.#### Sent: Tuesday, September 28, 1999 7:34 AM Subject: NanoGUI palette model > - If we're drawing on a true type (I assume including 15,16,24 and 32 bit > displays? Please assume 8bpp truecolor also - I need this for the Clio (it's an awful visual mode but I'm stuck with it). Regards, Brad | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: NanoGUI palette model
From: Timo Ketola ####@####.#### Date: 28 Sep 1999 14:52:03 -0000 Message-Id: <37F0D436.B3D0CB58@Epec.fi> "Bradley D. LaRonde" wrote: > ----- Original Message ----- > From: Vidar Hokstad ####@####.#### > To: ####@####.#### > Cc: ####@####.#### ####@####.#### > Sent: Tuesday, September 28, 1999 7:34 AM > Subject: NanoGUI palette model > > > - If we're drawing on a true type (I assume including 15,16,24 and 32 bit > > displays? > > Please assume 8bpp truecolor also - I need this for the Clio (it's an awful > visual mode but I'm stuck with it). > Please, add also 4bpp directcolor (16 level gray scale) into the soup. I have such a hardware (320x240 lcd) and I'm dreaming on using linux and NanoGUI with it. Linux frame buffer is working already. -- Timo | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: NanoGUI palette model
From: "Bradley D. LaRonde" ####@####.#### Date: 28 Sep 1999 15:06:12 -0000 Message-Id: <012b01bf09c2$077867a0$b8119526@ltc.com> ----- Original Message ----- From: Timo Ketola ####@####.#### To: <unlisted-recipients:; (no To-header on input)> Cc: ####@####.#### Sent: Tuesday, September 28, 1999 10:44 AM Subject: Re: NanoGUI palette model > Please, add also 4bpp directcolor (16 level gray scale) into the soup. I have > such a hardware (320x240 lcd) and I'm dreaming on using linux and NanoGUI with > it. Linux frame buffer is working already. What hardware is this? Are you porting linux to it? Regards, Brad | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: NanoGUI palette model
From: Timo Ketola ####@####.#### Date: 28 Sep 1999 15:24:23 -0000 Message-Id: <37F0DBCD.D4D8983B@Epec.fi> "Bradley D. LaRonde" wrote: > ----- Original Message ----- > From: Timo Ketola ####@####.#### > To: <unlisted-recipients:; (no To-header on input)> > Cc: ####@####.#### > Sent: Tuesday, September 28, 1999 10:44 AM > Subject: Re: NanoGUI palette model > > > Please, add also 4bpp directcolor (16 level gray scale) into the soup. I > have > > such a hardware (320x240 lcd) and I'm dreaming on using linux and NanoGUI > with > > it. Linux frame buffer is working already. > > What hardware is this? Are you porting linux to it? > > Regards, > Brad 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. Actually I have already ported linux to it. It wasn't very difficult even though it has no bios. I also have ported one of our applications to it (normally run on bare hardware). We are not yet using the linux in production but it may be near. The transition could be immediate if we only had good graphics development suite for linux on this kind of hardware P-) -- Timo | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: NanoGUI palette model
From: "Bradley D. LaRonde" ####@####.#### Date: 28 Sep 1999 15:32:39 -0000 Message-Id: <016501bf09c5$b6b92ee0$b8119526@ltc.com> ----- 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? Regards, Brad | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: NanoGUI palette model
From: Greg Haerr ####@####.#### Date: 28 Sep 1999 17:24:19 -0000 Message-Id: <01BF09A3.94C83050.greg@censoft.com> : I've started looking at whats required to combine the NanoGUI and Microwindows : drawing code (screen/common.c in Nano-X 0.5pre3 and devdraw.c in Microwindows : 0.83), and most of the differences are related to the changed palette : model. : : As far as I can see, the palette handling in MicroWindows is roughly like : this (Greg, correct me if I'm wrong, please...), some of which is shared : with Nano-X 0.5pre3: : : - All drawing is based on PIXELVAL, which is an opaque representation : of color on whatever screen device you're operating on. Yep : - When setting drawing color etc., you user COLORVAL's. COLORVAL is : an at least 32 bit integer. COLORVAL is always a 32 bit RGB format color value. If F_PALINDEX is set, then it's an index into the current palette. Otherwise, mwin converts the requested RGB value into a closest-matched color in the currently defined system palette. The system palette is reloaded on occasison my mwin to support 256 color pictures, etc. Microwindows manages all system palette requests, and starts by defining a small 48 color palette (or smaller if devpal4 or similar is linked in) This allows user programs to negotiate with predefined palettes, or have completed control of the color display. : - If we're drawing on a true type (I assume including 15,16,24 and 32 bit : displays? Currently, there's no support for 15 or 16 bit displays, but it'd be easy to add. But I'm not sure if the code does any transformations, and : it seems like the code expects COLORVAL to hold a 24 bit R,G,B value : for truetype displays), then COLORVAL == PIXELVAL. We might want to : differentiate between different types of truetype displays, and convert : COLORVAL to the appropriate type. PIXELVAL needs to become an unsigned long to support running on truecolor displays. I was about to add this, but I can't the damn aty framebuffer on my system to run in truecolor... Anyway, there needs to be a compile-time option to support truecolor or not, so that on smaller 16 bit systems PIXELVAL doesn't have to be a long, thus slowing drawcode quite a bit. If compiled for 24 or 32 bit truecolor, then the RGB COLORVAL can be "passed thru" directly to the COLORVAL, in GdFindColor. We still want to call the function, for top-level reasons. This should be very simple to add. : - If we're drawing on a palette based display, all values above F_PALINDEX : is considered to be indexes into a palette. If not, GdFindNearestColor() : is called. Yes. F_PALINDEX is not recomended, since the user application doesn't normally know how big the palette is, and shouldn't be recompiled, but I providied this for backwards compatibility with nano-X programs, and defined all the standard colors in this way. All the devpalX.c palettes have a required color order for the first 8, then first 16 colors. : - GdFindNearestColor() approximates the RGB value given, to a value in : the palette. Normally, yes. However, other routines may add the RGB value to the system palette, if there's room. : - It has calls to merge palettes from for instance a color pixmap with : the system palette (which in truecolor would just be the same as the : original), to prepare for drawing a pixmap etc. The palette merge code currently assumes that the user program knows when it will need to display two different 256 color bitmaps simultaneously, and will call a system palette reset function in between... : : I suggest that we go for this palette model, with a couple of modifications, : and I volunteer to reintegrate this palette code into Nano-X 0.5pre3, : so that it and Microwindows shares the same palette code. A _far_ better idea would be too merge pre3 into 0.83, since there's tons of other additions and bug fixes since then. All the nanoX stuff works in 0.83, and is under the src/nanox directory. I don't think there's many changes, other than the filename/directory name changes Alex introduced. All the driver model interfaces have been updated too, and pre3 won't run on anything but 32-bit framebuffer machines, not ELKS or SVGAlib. : : My suggested changes/concerns are these: : : - As mentioned above, it might be worth converting from a single RGB : representation in GdFindColor(), to the hardware specific one. On the : other hand this might also be done in the driver. But especially with : regard to merging palettes, I'd expect that having the returned palette : be a set of hardware specific values would be most efficient. Comments? I thought of this, and figured it wasn't time yet to introduce a complicated driver model yet. This makes porting much harder. On strange displays, a special devpalX.c can be built, and still use distance-cubed RGB matching to get to the hw PIXELVAL color. : - I'd like to treat truecolor the same as palette based systems with : regards to having an indexed palette. Since F_PALINDEX is defined : to be larger than any 24 bit RGB value, it's only a couple of lines. Well, that's why F_PALINDEX is in the upper 8 bits of 32. But all colors for applications should be COLORVALs, which include RGB or palette indices, as 32 bit values. : : That means that programs should work the same on both truecolor and : palette based systems: They either request a PIXELVAL corresponding : to a RGB value or a palette index, and the only difference is that : for truecolor displays the palette is software only. Definitely. The design is that user programs will run unmodified on various hardware, without knowledge of it. That's why I chose RGB. F_PALINDEX is of limited usefulness, but is quite fast and the standard colors defined in device.h all work on any device. : Greg | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: NanoGUI palette model
From: "Vidar Hokstad" ####@####.#### Date: 29 Sep 1999 07:24:21 -0000 Message-Id: <19990929071932.25326.qmail@mail.relight.com> On Tue, 28 Sep 1999 17:44:06 +0300 you wrote: >"Bradley D. LaRonde" wrote: > >> ----- Original Message ----- >> From: Vidar Hokstad ####@####.#### >> To: ####@####.#### >> Cc: ####@####.#### ####@####.#### >> Sent: Tuesday, September 28, 1999 7:34 AM >> Subject: NanoGUI palette model >> >> > - If we're drawing on a true type (I assume including 15,16,24 and 32 bit >> > displays? >> >> Please assume 8bpp truecolor also - I need this for the Clio (it's an awful >> visual mode but I'm stuck with it). >> > >Please, add also 4bpp directcolor (16 level gray scale) into the soup. I have >such a hardware (320x240 lcd) and I'm dreaming on using linux and NanoGUI >with >it. Linux frame buffer is working already. That can easily be handled. The palette code in Microwindows doesn't attempt to set any hardware palette, but just maps the palette the driver presents to any palette user attempts to set. In this case the hardware driver thus will only present a 16 level gray scale palette. Vidar Hokstad Screen Media AS | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: NanoGUI palette model
From: "Vidar Hokstad" ####@####.#### Date: 29 Sep 1999 08:59:00 -0000 Message-Id: <19990929085413.25720.qmail@mail.relight.com> On Tue, 28 Sep 1999 11:21:15 -0600 you wrote: >: My suggested changes/concerns are these: >: >: - As mentioned above, it might be worth converting from a single RGB >: representation in GdFindColor(), to the hardware specific one. On the >: other hand this might also be done in the driver. But especially with >: regard to merging palettes, I'd expect that having the returned palette >: be a set of hardware specific values would be most efficient. Comments? > > >I thought of this, and figured it wasn't time yet to introduce a complicated >driver model yet. This makes porting much harder. On strange displays, a >special devpalX.c can be built, and still use distance-cubed RGB matching >to get to the hw PIXELVAL color. It doesn't have to be complicated. GdFindColor just has to know how to map a 24 or 32 bit RGB value to the main types of RGB displays: 15/16/24/32 bits with different byte ordering. It can either be part of GdFindColor, or we can add a function to the drivers to do it. If we're going to support truecolor on all kinds of hardware it's something we'll have to deal with anyway. Normally you just want to strip the least significant bits and organize them correctly withing the 32 bit value. >: - I'd like to treat truecolor the same as palette based systems with >: regards to having an indexed palette. Since F_PALINDEX is defined >: to be larger than any 24 bit RGB value, it's only a couple of lines. > > >Well, that's why F_PALINDEX is in the upper 8 bits of 32. But >all colors for applications should be COLORVALs, which include RGB >or palette indices, as 32 bit values. Yes, but currently, if TRUECOLOR is defined, it doesn't let you use the palette - GdFindColor() just returns whatever value it's passed in and assumes that COLORVAL == PIXELVAL for truecolor displays. First of all, that isn't true for any displays that doesn't organize their color values the same way COLORVAL's are, second it means that any code that rely on palette indices won't work on truecolor displays at all, as far as I can understand. >: That means that programs should work the same on both truecolor and >: palette based systems: They either request a PIXELVAL corresponding >: to a RGB value or a palette index, and the only difference is that >: for truecolor displays the palette is software only. > > >Definitely. The design is that user programs will run unmodified on >various hardware, without knowledge of it. That's why I chose RGB. F_PALINDEX >is of limited usefulness, but is quite fast and the standard colors defined >in device.h >all work on any device. Does it? In GdFindColor(), if TRUECOLOR is defined and the driver returns a SCREENINFO structure that states that more than 256 colors are available, it just casts the COLORVAL to PIXELVAL and returns it. So if it is passed a palette index, you'll get "RGB" values of the type (F_PALINDEX | index), which certainly won't map to the right color. Or is there something I've overlooked? What I'm suggesting is only that if TRUECOLOR is defined that we get the RGB value from the palette if F_PALINDEX is set, so that palettes (including user defined) work on truecolor displays too. Regards, Vidar | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: NanoGUI palette model
From: "Bradley D. LaRonde" ####@####.#### Date: 29 Sep 1999 12:33:32 -0000 Message-Id: <004d01bf0a75$dc680840$b8119526@ltc.com> ----- Original Message ----- From: Vidar Hokstad ####@####.#### To: ####@####.#### ####@####.#### Cc: ####@####.#### Sent: Wednesday, September 29, 1999 4:54 AM Subject: RE: NanoGUI palette model > What I'm suggesting is only that if TRUECOLOR is defined that we get the > RGB value from the palette if F_PALINDEX is set, so that palettes (including > user defined) work on truecolor displays too. Are the palettes all static, defined by the driver? If so, then driver itself can map a passed palette index to RGB. Even if someday drivers allow modification of the hardware palette, the driver can still map RGB to index itself. The only value I see to the palette index flag is to have 8 or 16 "standard" colors that programs can count on, but even that is kind of superfluous - they can just specify a "standard" RGB (black, white, yellow, green, etc. like Netscapes color names) and let the driver do its best. As for the differences in mapping between RGB bit layouts, again, the driver can do the mapping, no? Regards, Brad | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 3 [>] [>>] |