Re: FVWM: Re: Colormap issues

From: Dan Espen <dane_at_mk.telcordia.com>
Date: Tue, 01 Oct 2002 18:03:56 -0400

Tim Freedom <tim_freedom_at_yahoo.com> writes:
> On 1 Oct 2002 08:37:31 +0200, Olivier Chapuis wrote:
> >
> > [snip snip]
> > >
> > > are very different in tone/color. A case in point, the clamp.xpm is
> > > yellowish in color when it should really be brown. If I invoke 'xv'
> > > from the command line and look at clamp.xpm, it looks fine (its brownish)
> .
> > > I don't have any "colormap" commands in my .fvwm2rc file (FWIW).
> > >
> > [snip snip]
> > >
> > > + snap-20020720: exhibits problems, faded + FvwmPager is green-puke colo
> r
> > > + snap-20020715: Works great
> >
> > Not exactly I think. In what follow I assume that you have a screen
> > which supports only 256 colors (8 bit depth). Can you confirm this?
>
> Here's the output of 'xdpyinfo'
>
> screen #0:
> depths (3): 1, 8, 24
> depth of root window: 8 planes
...
> I believe I have a raptor graphics card that is supposed to support alot
> more than 256 colors, anyone know how to alter this setting (or to verify
> that I'm capable of that) ?

xdpyinfo says your card can do three depths, b/w, 8 bit pseudocolor,
and 24 bit truecolor. The default however is 8 bit.

How you change this depends on your X server.

On a Sun, there are a few different commands, depending on your
hardware, one of them is m64config, the man page may help.

On Linux, look at your XF86Config file, it should be easy to spot
what needs changing, or use one of the GUIs supplied.

> > and start fvwm without the "-color-limit" option
> > (DitherIcon/NoDitherIcon are not dynamic, you should restart the
> > Buttons after a change). BTW, ditherIcon is an undocumented Colorset
> > option because maybe it will be removed. Also, there are not enough
> > doc about the -color-limit option as the code is not finished.
>
> Well, in short I don't use gradients (as I see that its a nicety that I
> can certainly live without), but I do expect to see my limited 8 icons
> to be displayed correctly. Maybe a 'EnableGradients on/off' might be
> something you'd consider.

Its not really necessary to do that if you do the -color-limit thingie.
We're still working on the documentation. One of the issues is
how will the user decide which of the many color limit choices
he should use.

> In any regard, I tried starting fvwm with '-color-limit 61' and that fixed
> my icon problems :-). Is there anyway I can put that option inside of my
> .fvwm2rc file ? Is there any reason why the "ColorLimit" command has been
> obsoleted ?

I think this stuff is still under development.
The need for the colorlimit command went away in the 2.4.x release,
the default colorlimiting was usually enough.

I think we still need to work out what the new default should be.

This is a beta, so your opinion, which I think you made clear,
won't be ignored.

> > You may also try to start fvwm with -color-limit 125 or 216.
> > But you will probably have pbs with certain apps you use
> > (or fix some pbs with some gtk apps).
>
> I'm satisfied with '61' colors I guess, no need to expand that number :-)

Olivier, I don't know if that will help, for one thing it will use
up more colors. I don't know if we discussed this before, but
the 61 color table had a lot of colors in it that were designed to
evenly fill the gaps in the perceptual (HVC) colorspace.
I believe the new
tables are optimized for gradients by spacing the colors evenly in
a linear colorcube. That can leave some pretty big gaps in
the perceptual colorspace.

Thats not to say that the 61 color color table won't turn gray
into pink or green, I've seen it do that.

I don't know if we discussed any color theory before, I hope this
stuff makes some sense to you (perceptual and linear colorspaces).
I'm not a color expert, but I did some
study of this stuff when I came up with the original 61 colors
and the matching algorithm. The matching algorithm in Fvwm is
not the algorithm used to create the 61 color color table, since
the perceptual match algorithm is too slow for Fvwm use.

I still have the source code for the program I used to fill in
the gaps if you're interested.

-- 
Dan Espen                           E-mail: dane_at_mk.telcordia.com
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Tue Oct 01 2002 - 17:08:04 BST

This archive was generated by hypermail 2.3.0 : Mon Aug 29 2016 - 19:37:53 BST