Subject: CVS olicha: * Implemented a new color limit method

From: FVWM CVS <[email-masked]>
Date: Wed, 17 Jul 2002 09:32:48 -0500

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
* a menuitem -Wall fix

--
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: Wed, 17 Jul 2002 16:27:17 +0200

> * 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

---

From: Dan Espen <[email-masked]>
Date: Wed, 17 Jul 2002 13:18:14 -0400

> colors respectively. The color tables come from imlib2.
...
> 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-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: Thu, 18 Jul 2002 08:33:34 +0200

> ruins the color map for everything else.

First, note that we can steel limit the colors by using the
FVWM_COLORLIMIT env variable (and an option, maybe, in the
future).  Maybe we may choose to change the default to 64 if
depth <= 8, I am not sure.  But, when I run my Xserver with depth
8 (and fvwm allocate these 216 colors) I *cannot* reproduce any
problems, I can run netscape, xv, gimp, any gtk/gnome apps, any
kde apps ..etc without any problems.  With the old method (with
any ColorLimit setting) what happen is that fvwm looks ugly (a
lot of colors simply become black and I've to choose very
carefully my fvwm colorset so that this does not happen) and the
other apps work in the same (good) way. If I limit the colors
with the new method, then fvwm is less pretty (but no noisy black
colors) and the other apps work again the same way.  One point is
that the 216 colors is a good palette and color allocation
succeed for all the colors.

So my question is:
"How I/you can reproduce a problem with the new method?"
(I do not say this is not possible).

The old method reduce colors in the good way only for xpm.  Now I
think we need to reduce colors for png, tinting and gradient.
Moreover, the most important thing concerning colors with a
pseudo color visual is that color allocation MUST never fail. I
do not see an other method that this color table method.

Olivier

---

From: Tim Phipps <[email-masked]>
Date: Thu, 18 Jul 2002 11:07:51 +0100

>
>
>But, when I run my Xserver with depth
>kde apps ..etc without any problems.
>
You may be being helped by your graphics card/Xserver. If your setup 
allows other colormaps to be active without deactivating the root 
colormap then it could be that netscape etc have allocated a private 
colormap and you don't notice. Other people on less advanced hardware will.

It could be that your apps are sophisticated enough to cope with low 
availability of colors. There are plenty of ancient CAD applications 
around that fall over in a big heap if they don't get every color they 
ask for.

>do not see an other method that this color table method.
Instead of allocating colors you can query the colormap and find a close 
match to the one you want and just use it. I'm not sure if it's possible 
to find out if  a color cell is allocated to another client or not so it 
may be that picking color cells like this leaves you exposed to the 
color of the cell changing. Maybe allocing the color of the cell (rather 
than the original color) would fix the cell color.

Cheers,
Tim.

---

From: Dan Espen <[email-masked]>
Date: Thu, 18 Jul 2002 06:56:12 -0400

...
...
> (I do not say this is not possible).

In my current setup, I have a background image limited to
using 48 colors.  With FVWM allocating 216 colors and
48 colors in the background, that leaves no colors for
applications.

I don't know why you aren't seeing a problem.

> think we need to reduce colors for png, tinting and gradient.

I would not expect to be able to use tinting or
gradients on an 8 bit display.

> do not see an other method than this color table method.

To make this work, you'd have to change the X server.

In Windows, they make this work by rebalancing the color map.
When the user allocates a new color, Windows looks at everything on
the screen and adjusts the color map to get as close as possible.

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 18 Jul 2002 12:58:48 +0000

> around that fall over in a big heap if they don't get every color they 

What Dan and Tim say is that there is old hardware and old applications
that cause a lot of color problems.

What Olivier says is that on modern hardware and with modern applications
FVWM looks better using a new colormap table method (no black colors for
new colors anymore). And he wants to keep an FVWM color limit centrally.

So maybe a solution is to find the correct condition to activate one or
another code. Or just leave it the way it is now, but print a warning on
the ColorLimit command saying it is now replaced with $FVWM_COLOR_LIMIT.

> gradients on an 8 bit display.

It may be not an option for a user. For example, he uses someone else's
configuration (fvwm-themes), or his own configuration from another
hardware. He may expect the same config automagically to look tolerably
well even on another hardware.

Of course, I myself don't run neither 8bpp nor old hardware, so ignore my
comments if they make no sence.

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Thu, 18 Jul 2002 10:04:34 -0400

> > colormap and you don't notice. Other people on less advanced hardware will.

Never heard of multiple 8 bit color maps except some references
to overlay planes, but I don't know much about them.

> > around that fall over in a big heap if they don't get every color they 

Framemaker refuses to start if it can't get the colors it
wants.  I have to run other locally developed apps that do the
same thing.

> new colors anymore). And he wants to keep an FVWM color limit centrally.

I'm not sure what "modern hardware" means.
8 bit colormaps aren't modern.

>From the description, gradients still didn't look good.

Having the window manager take almost all of a scarce resource
doesn't sound like a reasonable way to go.

> the ColorLimit command saying it is now replaced with $FVWM_COLOR_LIMIT.

I can't say I like the last option.
In my opinion, the old way works.

> well even on another hardware.

If you remember the mini-themes package I posted a while back,
it used cpp to eliminate the gradients in 8 bit environments.
Shouldn't fvwm-themes be doing something similar?

> comments if they make no sense.

I've coped with 8 bit for years and years.
The ColorLimit command helped a whole lot getting icons under control
and making Fvwm attractive.

I admit, I finally gave up, mainly because my Sun hardware wouldn't
go to 1600x1200 and I now use Linux for my home and work desktop.

The users I support at work are still mostly on 8 bit hardware.

---

From: Tim Phipps <[email-masked]>
Date: Thu, 18 Jul 2002 16:09:29 +0100

Olivier Chapuis wrote:

>I've implemented a new color limit method.
>
This doesn't work with a 24bit Truecolor display. I'm using todays 
snapshot (20020718), everything is black. If I #define THEOLDMETHODE it 
works OK.

>Again you should set FVWM_READWRITE_COLORS to 1 to enable
You might want to ask on the fvwm list if anyone is using this.

Cheers,
Tim.

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 18 Jul 2002 19:17:08 +0000

> Shouldn't fvwm-themes be doing something similar?

Some of the themes are specially built to have a small number of colors.
This may be finished when the currently included icon set 48x48-general
(it may be disabled in configuration) is replaced with 48x48-infox that
uses 15 colors in 84 icons. Together with mini icons (the included icon
set 16x16-kde uses 44 colors in 84 icons), background, modules and other
colors the default look should use no more than 100 colors. If colors@cde
and NoIcon used, there are 50 colors at most. ColorLimit is not required.

It is ugly to add a preprocessing code every time gradient or png used.
It would be much nicer if FVWM automatically handle this if possible.

Just like currently on black and white 1bpp displays all colors (at least
colorsets) automatically look more or less readable, they are replaced
with the predefined bitmaps.

Regards,
Mikhael.

---

From: Olivier Chapuis <[email-masked]>
Date: Thu, 18 Jul 2002 23:40:45 +0200

> snapshot (20020718), everything is black. If I #define THEOLDMETHODE it 

Is it fixed now?
Olivier

---

From: Dan Espen <[email-masked]>
Date: Thu, 18 Jul 2002 20:45:13 -0400

> and NoIcon used, there are 50 colors at most.  ColorLimit is not required.

Note that the old ColorLimit code used at most 61 colors.
Its unlikely all 61 would get used.
More importantly, the color allocation was heavily biased toward
"named" colors.  The idea was that the named colors would most likely
be chosen by other applications or users.  In effect, a lot less
than 61 colors were used by Fvwm, leaving lots of colors available.

Most of my icons are created by myself or my coworkers for new
systems we acquire.  We normally do some Google searches using
the system name for the new system and find an image we like.
For this, colorlimiting is a big help.

> It is ugly to add a preprocessing code every time gradient or png used.

It looked to me like png's were already being colorlimited.
Only gradients had to be avoided.
Gradients aren't going to work on 8 bit color without some
really good dithering.

Even with dithering, I have my doubts.

---

From: Tim Phipps <[email-masked]>
Date: Fri, 19 Jul 2002 10:01:38 +0100

>Olivier
Yes thanks,
Tim.

---

From: Olivier Chapuis <[email-masked]>
Date: Fri, 19 Jul 2002 23:48:11 +0200

> colormap and you don't notice. Other people on less advanced hardware will.

What it seems to happen is that, under depth 8, XFree (or at least the
2 Xserver that I can run on my laptop) allocate a color table at
startup of 244 colors. So there are only 12 free colors in the
colormap. This seems very few, but it seems to me that this is a very
reasonable way to implement sharded colors: there is no reason for a
client to take all the colors for itself and the X server decides for
all the clients almost all the colors.

I think that I've no problems with netscape et al. probably because
either the XFree color table is good or the apps take in account
XAllocColor failure in the good way (also, fortunately, the 216 colors
table that fvwm gives to me is a subset of the XFree table).

I am curious about what the others X implementation do.
 
> around that fall over in a big heap if they don't get every color they 

There are not only these old apps and Framemaker ... there are also
fvwm. I can have color allocation failure (and so noisy black)
colors with a config file which use very few colors.

> than the original color) would fix the cell color.

Yes, I think that this should work. But I do not think that this solve
the pbs I see with color limitation.

Olivier

---

From: Olivier Chapuis <[email-masked]>
Date: Fri, 19 Jul 2002 23:48:25 +0200

> > > ruins the color map for everything else.

Seems that this depends on the X implementation.

> 48 colors in the background, that leaves no colors for

With XFree we can "ruins the color map" with 13 colors (see my answer
to Tim). And in fact the 216 colors are a subset of the 244 colors
given by the server itself, so here the 216 table allocate no new
colors (but this is maybe/probably a coincidence).  Note that you can
steel reduce the nbr of color with the "new" (or tmp) method:

  env FVWM_COLORLIMIT=16 fvwm.

This is just a problem about default ("old" method use ~60 colors I
think). But I think that the problems is more complex than a number of
colors. You can allocate 13 colors and ruin your colormap and you can
allocate 216 one's without touching to any free one's (and the new
table with 16 colors really allocate more colors than the 216
table). In fact I try to use an other method because I get problems
with the "old" fvwm color table when I use it as is for reducing
colors for png and tinting (work fine with xpm as the xpm lib make a
part of the job). So in fact, if I well understand, what fvwm have to
do is to not allocate new colors if the number of free colors is <=
a given configurable number. I think this possible to implement, but
this is complicated and maybe slow.

> I don't know why you aren't seeing a problem.

Because I think that the installed colormap is good and the
apps I use are not broken.

> gradients on an 8 bit display.

But tinting work pretty well here in depth 8 and without Xrender.
About gradient I am agree, but I think this is because our
method to build gradien is weak. Here a Black to White Vgradient
with two colors:

  BBBBBBBBB
  BWBWBBBBB
  BBBBBWBWB
  BBWBWBWBB
  BWBWBWBWB
  WBWBWBWBW
  WWBWBWBWW
  WWWWWBWBW
  WBWBWWWWW
  WWWWWWWWW

> To make this work, you'd have to change the X server.

I think that the method Tim suggest (take the closest color in the
colormap) should work not so bad. The color table method do that in a
certain sens.

Olivier

---

From: Dan Espen <[email-masked]>
Date: Fri, 19 Jul 2002 20:32:55 -0400

> all the clients almost all the colors.

I don't think those 244 colors you see are allocated.
Thats the default state of the colormap.
If you attempted to use one of those colorcells,
they would change as soon as another app allocated a color
that happened to use that cell.

Using the colormap program I sent you, if the cell is allocated,
you'll see a slash thru it when you press "s".

> table that fvwm gives to me is a subset of the XFree table).

I don't know what kind of apps you are running, but
there needs to be a lot of free colors in the colormap,
or our users are going to have problems.
I guarantee it.
Before colorlimiting was implemented, we had
frequent reports of color allocation problems.
We still do when a user starts Netscape without -install,
although 8bit color is getting rarer.

> I am curious about what the others X implementation do.

Most X servers pre-allocate black and white, (2 colors).
(Solaris and XFree).

> the pbs I see with color limitation.

I still say tinting and gradients aren't going to work.

I didn't try png, but it looked like you had png working.

---

From: Olivier Chapuis <[email-masked]>
Date: Sun, 21 Jul 2002 10:59:38 +0200

> you'll see a slash thru it when you press "s".

Of course I used the program you send to me :o). If I start my Xserver
with just an xterm the "colormap" program says me that I've only 12
free colors. After that I made an other check to see the effect of the
"new" palette. I computed the number of free colors before and after
the "new" palette are allocated.  Again I get only 12 free colors
before any colors are allocated, the number of free colors after the
allocation of the palette depends on the palette.  With the 216
palette I still get 12 free colors as with the palette with 16 colors
I get only 4 free colors!

> or our users are going to have problems.

Why you do not trust me? I run my Xserver with depth 8 and I get no
problems with all the app I can run (including "netscape -no-install").

> Most X servers pre-allocate black and white, (2 colors).

Not my XFree-4.2 Xserver (with the neomagic or vesa driver).

AHHHHHH, I manage to run my old XFree-3.3.6 Xserver. Yes, in this case
only 2 colors is pre-allocated (black and white) and I can see the
netscape problems, gimp-1.2 and gtk+ 2 automatically use a private
colormap, and I see others various problems. If I use the 64 colors
palette I cannot see a lot of problems, but I am agree that allocating
64 colors at fvwm startup is not a very good idea.

> I still say tinting and gradients aren't going to work.

Tinting works fine here with XFree-4.2. With XFree-3.3 and 64 colors
it may works or not this depends on the image and tint.  Of course
gradient are ugly in both case (but never fully black).
 
> I didn't try png, but it looked like you had png working.

I get problems with png as I get color allocation failure in the "old"
color table. The "old" color limit works fine with xpm and go into 2
steps one done by fvwm the other one done by libXpm: the original
color name is replaced by fvwm by a color name in the table which
gives the closest color. Then, libXpm load the xpm by allowing a color
closeness of 40000, so I think that if the allocation of the reduced
color name fail libXpm try others colors until color allocation
succeed. So I think that with ColorLimit x, libXpm does not allocate
more than x colors but these x colors may be different than the x
first colors of the table.

When I implement color reduction for png I do it in one step: libpng
gives me rgb colors and I take the closest colors in the table. But I
get XAllocColor failure with the KDE icons set if I not use something
like ColorLimit 9. I also get AllocColor failure with tinting and ewmh
icons which use the same simple color limitation than png. Also with
XFree-4.2 you can get fvwm AllocColor failure even if a few colors are
used. So with XFree-4.2 you get very good result if you can found a
big color table which is a subset of the pre-allocated color
table. Also it seems that color limitation should be applied
everywhere (even for title, menu and module simple colors or fg, bg,
hi, sh colorset), if we do not want to use the 12 free colors.

So it seems that XFree-4.x used a drastically different method than
the others X implementation.

I will try to found a 3rd method which works with all X server.

Olivier

---

From: Dan Espen <[email-masked]>
Date: Sun, 21 Jul 2002 08:49:08 -0400

> problems with all the app I can run (including "netscape -no-install").

I trust you, I just never heard of an X Server that supported
8 bit that way.

I've done some Google searches and I still don't know whats
going on.

Is there some clue in the output from xdpyinfo?

Does you card allow multiple colormaps to be used at once?

Since you seem to have some new kind of 8 bit X Server,
I think your changes are good if you can find a way to
turn them on for this new X Server.

Sorry for my ignorance.

---

From: Tim Phipps <[email-masked]>
Date: Mon, 22 Jul 2002 10:30:07 +0100

>I've done some Google searches and I still don't know whats
It could be that Oliviers Xserver has standard colormaps created on it 
(by some startup script). They are created by xstdcmap I think, I'm not 
sure how to query the server for them but if they are there they will 
use up lots of color cells and many applications will use them. If this 
is the case maybe we should think about getting fvwm to support them.

Cheers,
Tim.

---

From: "Dmitry Yu. Bolkhovityanov" <[email-masked]>
Date: Mon, 22 Jul 2002 16:25:33 +0700

> turn them on for this new X Server.

	Maybe Olivier has a Matrox card, which supports two visuals
simultaneously (24+8 overlay mode)?  But the RENDER extension, which
steals most of the colormap cells in 4.2, isn't loaded in overlay mode.

	Olivier, which hardware do you use?  AFAIR, there was some
graphics hardware from either DEC, SGI or HP, which allowed to use several
hardware colormaps in 8-bit mode (in fact that was a kind of overlay), but
I didn't know that PCs also support this feature, so I'm very curious.

	_________________________________________
	  Dmitry Yu. Bolkhovityanov
	  The Budker Institute of Nuclear Physics
	  Novosibirsk, Russia