On Sun, Aug 11, 2002 at 03:17:20AM -0500, FVWM CVS wrote:
> Log message:
> * New color limit method and implement dithering in depth <= 8
>
Hello,
So here how this new method works:
* First some general remarks:
- Color limitation is enabled only if the depth <= 8 (it was possible
to use color limitation for depth < 20 but color limitation is not
useful, I think, for depth 15 and 16). Also, pixels are stored for
gradient and xpm image only if this is needed (this save some memory
in depth > 8 and in depth <= 8 under certain mode).
- I've added a special handling for GrayScale visuals (by using grey
color tables). For simplicity, in what follow I assume PseudoColor
visual and depth 8 (the number of map entries in the color map is take
in account when a default number of colors is computed).
- I've added "dithering" for xpm, png and gradient. It seems to me
that this gives good results for gradient (need hight resolution for
colorset gradient). For images, it depends on the image. Dithering is
on by default for colorsets and can be disabled/enabled with the new
colorset options nodither/dither. For icons (and image loaded by
modules) dithering is off by default and can be enabled by using new
colorset options ditherIcon/noDitherIcon (this is not dynamic yet).
Mini-icon and menu icons are not dithered (yet?). Non colorset
gradient (menu and title style) are dithered by default and this
cannot be disabled (gives better result than colorset gradient ...). I
think that I will add dithering for depth <= 16 (for fine gradient,
off by default).
- Colors allocation never fail now. If it is not possible to X
allocate a given color the close color in the colormap is chosen.
* How the color table is chosen:
- first fvwm try to detect if a "standard" color table is
"pre-allocated". Fvwm try to detect the 6x6x6 (216 colors), 6x6x5 (180
colors), 6x6x4 (144 colors), 5x5x5 (125 colors), 5x5x4 (100 colors)
and the 4x4x4 (64 colors) color cube. If this is the case fvwm use
this table for color limitation, also this table is used in a static
way: the table is reallocated by fvwm and no colors from this table is
freed (note that this save memory as we do not need to store the
allocated pixels).
This happen with XFree-4.? and a server with xrender support. I think
that this happen if you run KDE or GNOME with fvwm as window manager.
- If no pre-allocated "big" table is found a default behavior should be
chosen. I do not think that there is a best default. The current
default is to use the 4x4x4 colors cube (as the cvs XRender ext). But,
the table is not pre-allocated. Only the colors which are needed by
fvwm are allocated in this table (with possible approximation in the
colormap). Also, fvwm try to use dynamic colors: if *possible* pixels
are stored when an xpm is loaded or a gradient is created and the
colors are freed when the xpm or the gradient is destroyed. This was/is
well implemented with gradient (may take a lot of memory). This was
well implemented with xpm (but for xpm icons ??). This is/was not
implemented for EWMH icons and png images and this is not implemented
for dithered xpm. It will not be difficult to implement full dynamic
colors but this leads to some problems of memory or speed. For example
when you dither an xpm you do not have any more the arrays of colors;
you have one colors for each point of the image. So, you should store
an array of pixels of the size of the image (lot of memory; what I do
with gradient) or you should sort and pack all the pixels of the
images (speed problems). My conclusion is that it is probably better
to use "static colors" for the colors *in* the table. But I've no
objection to finish the implementation of dynamic colors.
Any comments?
- Why I do not use Dan named color table as default? Note first that
this table can still be used (maybe needs a fix for better
approximation of the "grey"). The point is that dithering computation
(and fast allocation) depends on a regular table as a color cube.
With the named table, for dithering, the table is approximated by a
color cube (the 4x4x4 color cube with 61 colors and with the 3x3x3
color cube with 9 colors) and computation is done in the cube. This
leads to a less fine dithering (fast allocation is done by
approximating the named table by a 16x16x16 or a 8x8x8 color cube).
- The above default logic can be override by a new option to fvwm
"-color-limit nc[:A]" where nc is a number of colors and A an array of
the 0 and 1's. The limit value for nc are 216 (6x6x6 cc), 180 (6x6x5),
144 (6x6x4), 125 (5x5x5 cc), 100 (5x5x4), 64 (4x4x4), 61 (Dan color
named table), 48 (4x4x3), 27 (3x3x3 color cube), 9 (Dan color named
table), 8 (2x2x2), 4 (4 grey's) and 2 (black/white). By default
A=0010. If A=abcd:
- if a == 1 fvwm use a strict color limit logic; *all* the colors
than fvwm allocate are taken from the colors table!
- if b == 1 Dan color named table is enforced
- if c == 0 fvwm does not use dynamic colors in the table.
- if d == 1 fvwm chooses the "first" table where full pure X allocation
succeed, the table is pre-allocated and static colors are used in the
table (force c=0).
The -color-limit option can be override by an env variable FVWM_COLORLIMIT.
- Examples:
* XFree-4.2 with an xrender server simulation or you mainly use gtk
and qt apps: 216:0001
* XFree-4.3 with an xrender server simulation: 64:0001
* You do not want that gtk apps install a private colormap: nc:0001
with nc = 216, 180, 144 or 125
* You have an xserver which allocate only 2 colors
- lots of colors but strict 125:1
- all the colors for the apps 4:1
- Dan table 9 or 61 or any:01
- The modules use the same table and logic as fvwm. At present time an
env variable is used FVWM_COLORTABLE_TYPE describe the table and the
logic that fvwm used.
- TODO: doc, cleanup (e.g., Scr.ColorLimit is obsolete or should
contains the value that FVWM_COLORTABLE_TYPE contains), maybe complete
the dynamic colors implementation, take in account the answer to this
mail.
*
* Unfortunately, I will not be able to read my mail and commit changes
* between the 13th and the 29th of august.
*
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]
