On 08 Oct 2002 23:46:38 +0200, Olivier Chapuis wrote: > > On Tue, Oct 08, 2002 at 03:38:06PM +0000, Mikhael Goikhman wrote: > > 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. > > 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).
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. -- 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]
