Mikhael Goikhman wrote:
Here is another formula for stretching DGradient that I had in mind
when wrote the original message, it is none of the existing two:
get_color_index(x, y, size_x, size_y, colors_num)
{
(x / size_x + y / size_y) * colors_num / 2
}
This should produce something like:
11111....333
111....3333:
1....3333:::
...3333::::5
.3333::::555
333::::55555
This is nice. I think the way colorsets are stretched at the moment is a
result of trying too hard to keep the code small. The existing code
stretches the gradient horizontally to the window width
and then stretches the resulting intermediate pixmap vertically to fit
the window height. This reuses the horizontal and vertical streching
code used for HGradients and VGradients. There's no reason not to add
your algorithm in for colorsets that need to be streched both ways. It
would help all the gradients (apart from V & H) become less blocky.
The code to change is in CreateStretchPixmap() in libs/Graphics.c. It
currently does a CreateStretchXPixmap() followed by a
CreateStretchYPixmap().
The downside is performance for large areas and I'm not sure if it would
be an improvement for colorsets that use a small pixmap file as a
non-tiled background (but they look bad anyway)
Compare with the existing ones:
1111....3333
1111....3333
....3333::::
....3333::::
3333::::5555
3333::::5555
Hmm, Tetris! Maybe we could create a game in Fvwm using FvwmForm/Script
to capture keystrokes and fire off Colorset definitions 8-).
Cheers,
Tim.
--
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]
