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. - Color limit is applied to *all* colors in the following way: for gradient and "pixmap" the color table is used. For the others colors (e.g., fg, bg, ...etc colorset or simple colors for menus, window title, modules ...), first the code tries to allocate the color and if this fail, then the color is taken from the color table. The main advantage of this method is that color allocations never fail. So, you do not have "all" the colors replaced by the black color if you use too much colors when running with depth <= 8. An other important difference is that color limit is applied to gradients. There are performance issue too. The disadvantage is that the ColorLimit cmd is obsolete: the color limit should be defined before the first color is allocated so it is difficult to use an fvwm config cmd to define it. Also it is not clear (for me) if it is possible to jump between the color tables at running time. So I've used a env variable: FVWM_COLORLIMIT (and I'will add an option to fvwm if we decide to use the new method) which overrides the default color limit (256 if the depth <= 8, no limit if not). But, I hope that the color tables are good enough and that specifying a color limit is not really needed. Also the "colorset cmd" ReadWriteColors is also obsolete for similar reason (it is broken in 2.5.x since a few weeks). Again you should set FVWM_READWRITE_COLORS to 1 to enable read-write colors. In fact, my main concern is "does the new method work on any hardware?". So, please test with the various depth (<= 8) that your X driver support. There is a debugging message (at fvwm startup) which tells you which color table is used. 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). I've not removed the "old" code. To get it you should: #define USE_OLD_COLOR_LIMIT_METHODE in config.h (sorry for the ending "E" :o) I will remove it if there are no objection with the new code. Regards, 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]
