Subject: Re: CVS olicha: * New color limit method and implement dithering in depth <= 8

From: Olivier Chapuis <[email-masked]>
Date: Fri, 6 Sep 2002 10:23:44 +0200

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-masked].
To report problems, send mail to [email-masked]

---

From: Dan Espen <[email-masked]>
Date: Sun, 08 Sep 2002 10:02:04 -0400

>    the XRender extension may use simple colors config.

The more you can do to limit color use by FVWM the better.
Using a restart doesn't seem good.

I'm concerned about how complicated this has become.
I haven't figured out how a user would figure out which
options to use.  I know you haven't finished the documentation yet.

-- 
Dan Espen                           E-mail: [email-masked]
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-masked].
To report problems, send mail to [email-masked]

---

From: Olivier Chapuis <[email-masked]>
Date: Sun, 8 Sep 2002 23:31:12 +0200

> Using a restart doesn't seem good.

Yes, but I am not sure we win a lot by freeing the colors allocated in
the table. On the other hand this may take a lot of memory or make
the loading of certain image/gradient slow.
 Ok, I will not remove the possibility to free colors in the table and
fixes these "weak" colors leaks when possible at feature freeze time.

> options to use. 

Yes there is more configuration possibility. But there are a lot of
situation we have to deal with as the good option depends on the
applications the user use. fvwm can now share its colors with XRender,
qt and gtk (this is where a lot of colors may be a good things).
Moreover, this is done automatically when possible (auto detection of
"pre-allocated" table).
Also, an interesting new possibility is that color limit can be
applied to _all_ the colors used by fvwm (some effort may be done on
the sh/hi colors in the future).
So the situation is as before: 1. do nothing, 2. If you get problem
try to limit the colors (and for gtk pbs try to ask fvwm to
pre-allocate a lot of colors!).

> I know you haven't finished the documentation yet.
> 

I will try to wrote a clear doc.

Olivier