Subject: Colorset enhancements

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 8 Oct 2002 15:38:06 +0000

The colorset enhancement may be calculating relief colors differently.
Currently, we use sh and hi (that is evaluated from bg if not given) to
do this. Such static colors produce bad results when used for gradient,
image or transparent background with a large or medium range of colors.

It would be better to have a boolean flag in colorset that switches off
the use of the hi and sh in colorset and evaluates hi and lo using the
internal algorithm based on the real-time bg pixel that should be
converted to the relief. The problems are clear. This is slower and not
very configurable. I wish the gtk color algorithm to be used in this case,
not motif's, otherwise it will be not smooth for random gradient/image.
Still regardless of problems, this should produce a much nicer result.

As for configurability, I think it is good to extend the colorset to have
a flag that chooses gtk-based or motif-based calculations. And hiFactor,
shFactor that are used in gtk-based (and maybe in motif-based) algorithms.
Probably these 3 values may be global for all colorsets to make it easier
for the user to define them. Or we may add Colorset * syntax.

----

One more issue to think about. Using numbers for colorsets is ok, but
using symbolic names is better yet. Technically it may be implemented
using one array (for numeric names) and one hash (for symbolic names).
These array and hash have no any correlation. Anyone may choose either
numeric or text id for colorset. Like:

  Colorset CDE4 bla-bla
  Colorset MENU1 bla-bla
  Colorset MENU2 bla-bla

  MenuStyle * MenuColorset MENU1, ActiveColorset MENU2

Preprocessing may be a solution, but this is really not the same as the
colorset library managing these ids itself.

Regards,
Mikhael.
--
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: Tue, 8 Oct 2002 23:46:38 +0200

On Tue, Oct 08, 2002 at 03:38:06PM +0000, Mikhael Goikhman wrote:
> converted to the relief.

What do you mean exactly?

"bg average" gives in general a good color with image and gradient
colorset. With Transparent average does not work, but it may be
implemented if the server support backing store (by taking a random
20x20 part of the root window and averaging on this part). Average
slow down colorset loading (~ *2 with an image).

> The problems are clear. This is slower and not

No Objection.

> colorset library managing these ids itself.

No Objection. It will be good to have "private" colorset too.
A module may need to have a colorset for its own use only. 

Olivier

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 9 Oct 2002 15:56:51 +0000

> slow down colorset loading (~ *2 with an image).

I don't speak about average bg that is one single colors, I speak about an
ability to draw the 3d relief based in the current or neibour colors as
opposed to using one single hi and one single sh colors.

Take a look at some WindowMaker screenshots, like:

  http://www.chez.com/laurentpif/linux_images/wmaker1.gif
  http://windowmaker.org/images/screenshots/gradients.png

There are definitely better screenshots (I don't have a time to search for
them) showing how exactly hi and sh may be evaluated. The idea is this.
There is a rectangle with image or gradient, the edges of this rectangle
should be converted to a relief, they simply tinted with black or white!

Suppose, we have this rectangle (don't take the numbers too seriously):

  44444555556666677777
  44455555555556666677
  45555555555555556666
  55555555566666666666
  55555566666666666677
  66666666666667777777

It is better to be converted to:

  66666777778888899999
  64455555555556666675
  65555555555555556664
  75555555566666666664
  75555566666666666675
  44444444444445555555

Currently it is converted to something like (if bg average=6):

  77777777777777777777
  74455555555556666675
  75555555555555556665
  75555555566666666665
  75555566666666666675
  75555566666666666675
  55555555555555555555

> > The problems are clear. This is slower and not very configurable.
> > I wish the gtk color algorithm to be used in this case, not motif's,
> > otherwise it will be not smooth for random gradient/image. Still
> > regardless of problems, this should produce a much nicer result.

Regards,
Mikhael.