On Wed, Jul 17, 2002 at 01:18:14PM -0400, Dan Espen wrote: > Olivier Chapuis <[EMAIL PROTECTED]> writes: > > On Wed, Jul 17, 2002 at 09:32:48AM -0500, FVWM CVS wrote: > > > CVSROOT: /home/cvs/fvwm > > > Module name: fvwm > > > Changes by: olicha 02/07/17 09:32:48 > > > > > > Modified files: > > > . : ChangeLog > > > fvwm : builtins.c colorset.c fvwm.c menuitem.c > > > libs : ColorUtils.c Graphics.c PictureBase.c > > > PictureGraphics.c PictureImageLoader.c > > > PictureUtils.c PictureUtils.h > > > modules : ChangeLog > > > modules/FvwmIconMan: x.c > > > modules/FvwmScript: Instructions.c types.h > > > modules/FvwmWharf: stepgfx.c > > > > > > Log message: > > > * Implemented a new color limit method > > > > Hello, > > > > I've implemented a new color limit method. It goes at follow: > > > > - At startup if color limitation is needed, a color table is > > created (in fact allocated). > > Various color tables are tried. The first (best) color table > > is chosen: given a color table, the code tries to allocate > > all the element of the table, if one allocation fail the > > allocated colors are freed and the next table is tested. > > The color tables contain 256, 216, 128, 64, 32, 16, 8, 2 > > colors respectively. The color tables come from imlib2. > ... > > I can run my driver with depth 8, I get the 216 color table > > (and I can enforce color tables 2, 8, 16 but not the others). > > Now I can run fvwm-themes with depth 8 with a not too bad > > result. Gradient are no pretty, but to fix this we should > > implement a kind of dithering for gradient (dithering for > > large pixmap will be good too). > > If Fvwm allocates 216 colors, that leaves 40 for other > purposes. Thats no good. > > I've had to use 8 bit color in the past. > > Any application that takes the approach you have Fvwm taking > ruins the color map for everything else. >
First, note that we can steel limit the colors by using the FVWM_COLORLIMIT env variable (and an option, maybe, in the future). Maybe we may choose to change the default to 64 if depth <= 8, I am not sure. But, when I run my Xserver with depth 8 (and fvwm allocate these 216 colors) I *cannot* reproduce any problems, I can run netscape, xv, gimp, any gtk/gnome apps, any kde apps ..etc without any problems. With the old method (with any ColorLimit setting) what happen is that fvwm looks ugly (a lot of colors simply become black and I've to choose very carefully my fvwm colorset so that this does not happen) and the other apps work in the same (good) way. If I limit the colors with the new method, then fvwm is less pretty (but no noisy black colors) and the other apps work again the same way. One point is that the 216 colors is a good palette and color allocation succeed for all the colors. So my question is: "How I/you can reproduce a problem with the new method?" (I do not say this is not possible). The old method reduce colors in the good way only for xpm. Now I think we need to reduce colors for png, tinting and gradient. Moreover, the most important thing concerning colors with a pseudo color visual is that color allocation MUST never fail. I do not see an other method that this color table method. Olivier -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
