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. -- Dan Espen E-mail: [EMAIL PROTECTED] 444 Hoes Lane Room RRC 1C-214 Phone: (732) 699-5570 Piscataway, NJ 08854 -- 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]
