[<<] [<] Page 1 of 2 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
proposed change to microwindows color values
From: Greg Haerr ####@####.#### Date: 14 Oct 1999 20:19:31 -0000 Message-Id: <01BF164E.DB78F220.greg@censoft.com> Vidar/Brad, I wanted to document a change I'm planning for the color support for the nanox and microwindows engines. The changes doesn't have any implications for user programs or widget sets, but I thought I'd get everyone's opinion. Basically, currently microwindows assumes that the system will always have 16 colors available for drawing. This assumption proved false with the port to 2bpp machines like the MIPS based Everex Freestyle. Because of this assumption, I previously added color constants in device.h (WHITE, RED, LTGRAY....) that use the F_PALINDEX flag to allow microwindows to get the color _damn_fast_ without the need for using the distance-cubed method of finding a nearest color. Unfortunately, when microwindows is compiled with different devpalX.c files, this assumption can't work because the palette will get over-indexed. So a proposal is to move to color constants that are always RGB, and always compute the value regardless whenever a draw is needed. Currently, the only potential problem area is that of fast bitmap drawing, since the overhead for fillrect etc is minimal. Also, the idea of compiling in separate devpalX.c files is not going to work, since now microwindows can run on most any framebuffer device, any size palette, and many truecolor modes. Comments? Greg | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: proposed change to microwindows color values
From: Alan Cox ####@####.#### Date: 14 Oct 1999 20:25:01 -0000 Message-Id: <E11brGw-0003hm-00@the-village.bc.nu> > will always have 16 colors available for drawing. This assumption proved > false with the port to 2bpp machines like the MIPS based Everex Freestyle. > Because of this assumption, I previously added color constants in device.h > (WHITE, RED, LTGRAY....) that use the F_PALINDEX flag to allow > microwindows to get the color _damn_fast_ without the need for > using the distance-cubed method of finding a nearest color. Unfortunately, > when microwindows is compiled with different devpalX.c files, this assumption > can't work because the palette will get over-indexed. How about providing an array of 'best effort' for the base colours, black white dark grey and light grey ? The driver could set these up at setup time, and the application can do some kind of GetSystemColours(array, len) to get them. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: proposed change to microwindows color values
From: "Bradley D. LaRonde" ####@####.#### Date: 14 Oct 1999 20:36:10 -0000 Message-Id: <01c601bf1682$c59af690$b8119526@ltc.com> ----- Original Message ----- From: Greg Haerr ####@####.#### To: 'Vidar Hokstad' ####@####.#### 'Bradley D. LaRonde' ####@####.#### Cc: ####@####.#### Sent: Thursday, October 14, 1999 4:17 PM Subject: proposed change to microwindows color values > Vidar/Brad, > I wanted to document a change I'm planning for the color > support for the nanox and microwindows engines. The changes > doesn't have any implications for user programs or widget sets, > but I thought I'd get everyone's opinion. > > Basically, currently microwindows assumes that the system > will always have 16 colors available for drawing. This assumption proved > false with the port to 2bpp machines like the MIPS based Everex Freestyle. > Because of this assumption, I previously added color constants in device.h > (WHITE, RED, LTGRAY....) that use the F_PALINDEX flag to allow > microwindows to get the color _damn_fast_ without the need for > using the distance-cubed method of finding a nearest color. Unfortunately, > when microwindows is compiled with different devpalX.c files, this assumption > can't work because the palette will get over-indexed. > > So a proposal is to move to color constants that are always RGB, > and always compute the value regardless whenever a draw is needed. Currently, > the only potential problem area is that of fast bitmap drawing, since the overhead > for fillrect etc is minimal. Also, the idea of compiling in separate devpalX.c > files is not going to work, since now microwindows can run on most any > framebuffer device, any size palette, and many truecolor modes. > > Comments? I made the same (incorrect) 16-color assumption that you did, not thinking about those very limited greyscale screens. I think you've hit the nail right on the head as far as the solution goes. And yes, the added overhead for doing it this way is very small in most cases. However, we are already doing a conversion palette for bitmaps, so I'm not sure it will even add overhead there. Maybe it will even end up slightly reducing the total overhead as we might be able to do less checking and branching on the F_PALINDEX bit. Regards, Brad | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: proposed change to microwindows color values
From: "Bradley D. LaRonde" ####@####.#### Date: 14 Oct 1999 20:39:32 -0000 Message-Id: <01d401bf1683$428fcb30$b8119526@ltc.com> ----- Original Message ----- From: Alan Cox ####@####.#### To: ####@####.#### Cc: ####@####.#### ####@####.#### ####@####.#### Sent: Thursday, October 14, 1999 4:14 PM Subject: Re: proposed change to microwindows color values > > will always have 16 colors available for drawing. This assumption proved > > false with the port to 2bpp machines like the MIPS based Everex Freestyle. > > Because of this assumption, I previously added color constants in device.h > > (WHITE, RED, LTGRAY....) that use the F_PALINDEX flag to allow > > microwindows to get the color _damn_fast_ without the need for > > using the distance-cubed method of finding a nearest color. Unfortunately, > > when microwindows is compiled with different devpalX.c files, this assumption > > can't work because the palette will get over-indexed. > > > How about providing an array of 'best effort' for the base colours, black white > dark grey and light grey ? The driver could set these up at setup time, and > the application can do some kind of > > GetSystemColours(array, len) > > to get them. That ends up adding a lookup everywhere that system colors are used, which kinda defeats (though not completely) the idea of a hardware palette index in the first place. However, along the same lines maybe we can do some caching in the RGB-to-hardware conversion for non-truecolor displays, although I don't know that it would offer much overall improvement. Regards, Brad | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: proposed change to microwindows color values
From: Greg Haerr ####@####.#### Date: 14 Oct 1999 20:46:05 -0000 Message-Id: <01BF1652.743F0640.greg@censoft.com> : How about providing an array of 'best effort' for the base colours, black white : dark grey and light grey ? The driver could set these up at setup time, Alan, Your idea is similar to something we've discussed. One idea was that the "default" be laid out in a way such that it is downward compatible from 16 -> 8 -> 4 -> 2 color. So it might be laid out like: BLACK ; valid for 2,4,16 WHITE ; valid for 2, 4, 16 LTGRAY ; valid for 4, 16 GRAY ; valid for 4, 16 RED ; valid for 16 etc The only problem is this still won't work for static_pseudocolor systems that might have a different layout, as well as requiring that the system be ported to have a writable palette before _any_ screen driver will work, which is a pain, since most operating systems don't store their values in this order. The other answer was to statically build a reverse palette lookup table, based on the system palette, read only or not. but then alot of the gain of the F_PALINDEX bit is lost, since we're looking up two tables to get anywhere anyway... Greg | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: proposed change to microwindows color values
From: Greg Haerr ####@####.#### Date: 14 Oct 1999 20:50:20 -0000 Message-Id: <01BF1653.0C1F55A0.greg@censoft.com> : That ends up adding a lookup everywhere that system colors are used, which : kinda defeats (though not completely) the idea of a hardware palette index : in the first place. So if we go with the idea that user programs _always_ specify color with RGB only, then the overhead remains only on the palette-based systems, and truecolor systems fly. there will always be more overhead on palette systems, anyway. BTW, we can still keep the F_PALINDEX bit and use it, but leave it to the applications programmer to make sure that the system palette is big enough. Then the only issue remains with the conversion of our internal bitmap structure just before displaying the bitmap; that is, a new palette is created that maps the bitmap values to the nearest color system palette indexes just before display. If the bitmap's are ID'd (new concept for microwindows) then this palette conversion only has to be done once, and the changed palette will remain valid until the next system palette change. Greg | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: proposed change to microwindows color values
From: Alan Cox ####@####.#### Date: 14 Oct 1999 21:05:11 -0000 Message-Id: <E11bru6-0003kj-00@the-village.bc.nu> > The only problem is this still won't work for static_pseudocolor systems It does because its an indirection. > that might have a different layout, as well as requiring that the system Its not a colour table, its a table of colour numbers - indexes into the main table. For example it might be that white is colour 0 on an LCD and STDCOLOR_BLACK is 1. If so then colors[STDCOLOR_BLACK]= 0. On a mono display I guess red/blue/green map t black and yellow/... to white No problems | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: proposed change to microwindows color values
From: "Bradley D. LaRonde" ####@####.#### Date: 14 Oct 1999 21:10:28 -0000 Message-Id: <020a01bf1687$97007990$b8119526@ltc.com> ----- Original Message ----- From: Greg Haerr ####@####.#### To: 'Bradley D. LaRonde' ####@####.#### Alan Cox ####@####.#### Cc: ####@####.#### ####@####.#### Sent: Thursday, October 14, 1999 4:47 PM Subject: RE: proposed change to microwindows color values > : That ends up adding a lookup everywhere that system colors are used, which > : kinda defeats (though not completely) the idea of a hardware palette index > : in the first place. > > > So if we go with the idea that user programs _always_ specify color > with RGB only, then the overhead remains only on the palette-based systems, > and truecolor systems fly. there will always be more overhead on palette > systems, anyway. BTW, we can still keep the F_PALINDEX bit and > use it, but leave it to the applications programmer to make sure that the system > palette is big enough. Yeah, there probably isn't that much overhead to be saved by eliminating the checks for that bit from devdraw.c. I wonder if we should give applications a way to know what's in the standard palette. > Then the only issue remains with the conversion of our internal bitmap > structure just before displaying the bitmap; that is, a new palette is created > that maps the bitmap values to the nearest color system palette indexes > just before display. If the bitmap's are ID'd (new concept for microwindows) > then this palette conversion only has to be done once, and the changed palette > will remain valid until the next system palette change. Good optimization idea. Regards, Brad | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: proposed change to microwindows color values
From: Greg Haerr ####@####.#### Date: 14 Oct 1999 21:13:36 -0000 Message-Id: <01BF1656.66C1F910.greg@censoft.com> : Its not a colour table, its a table of colour numbers - indexes into the main : table. For example it might be that white is colour 0 on an LCD and : STDCOLOR_BLACK is 1. If so then colors[STDCOLOR_BLACK]= 0. : Yes. That's what I was trying to say. So - should we build this table from scratch, or just link in one that will work? Also, do you believe we should do this just to keep "simple" palette indices working, or move to RGB for user programs? : On a mono display I guess red/blue/green map t black and yellow/... to white : Yes, or at least the lobright to black and hibright to white. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: proposed change to microwindows color values
From: "Bradley D. LaRonde" ####@####.#### Date: 14 Oct 1999 21:15:05 -0000 Message-Id: <021a01bf1688$3be0e120$b8119526@ltc.com> ----- Original Message ----- From: Alan Cox ####@####.#### To: ####@####.#### Cc: ####@####.#### ####@####.#### ####@####.#### ####@####.#### Sent: Thursday, October 14, 1999 4:55 PM Subject: Re: proposed change to microwindows color values > > The only problem is this still won't work for static_pseudocolor systems > > It does because its an indirection. I thought about this. The thing is, why add the indirection to every call, especially if we can find a way to optimize (cache maybe) the dist-cubed thing for 4bpp? When it comes down to it, any overhead from the indirection or dist-cubed whether optimized or not is probably too small to notice for the most part anyway, so adding the indirection might just compilcate things for no real gain. Regards, Brad | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 2 [>] [>>] |