On Sun, Aug 11, 2002 at 11:48:19PM +0200, Olivier Chapuis wrote:
> 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
> >
>
>
> 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).
>
> [....]
> * How the color table is chosen:
>
> - [... when the default is easy to choose: pre-alloc table ]
>
> 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?
>
Ok, so I suggest this:
- By default here (no already pre-allocated), use a non preallocated static
table. And even:
- Never free colors allocated in the table, but always free colors
allocated outside. This is a bit "weak" but this seems reasonable
for me as restart can free the colors (sic) and 8 depth users without
the XRender extension may use simple colors config.
Dan?
>
> - [ ... about the named color table]
>
> - 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).
>
what about 3 options:
--color-limit
--strict-color-limit
--named-color-table
?
>
> [ ... Examples:]
>
> - 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: see if we can use the fvwm->module ColorLimit message or make
this message obsolete and remove Scr.ColorLimit (maybe reasonable).
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]
