Subject: colorsets initialization

From: Brad Giaccio <[email-masked]>
Date: Tue, 17 Aug 1999 08:11:13 -0400

it seems if I start up a module after initialization, the colorsets are not right.

The two modules I'm looking at are FvwmPager and FvwmIconMan

IconMan gives 
FvwmIconMan: X Error:
FvwmIconMan:          error code: 9
FvwmIconMan:          request code: 53
FvwmIconMan:          minor code: 0
FvwmIconMan: Leaving a core dump now

gdb where gives
#0  0xfefd9968 in __sigprocmask () from /usr/lib/libthread.so.1
#1  0xfefcf1f0 in _resetsig () from /usr/lib/libthread.so.1
#2  0xfefce93c in _sigon () from /usr/lib/libthread.so.1
#3  0xfefd17b4 in _thrp_kill () from /usr/lib/libthread.so.1
#4  0xff0392e0 in abort () from /usr/lib/libc.so.1
#5  0x1c7b0 in handle_error (d=0x3ad70, ev=0xffbee528) at x.c:848
#6  0xff237154 in _XError () from /usr/local/X11R6/lib/libX11.so.6.0
#7  0xff233a78 in _XWaitForWritable () from /usr/local/X11R6/lib/libX11.so.6.0
#8  0xff2340a4 in _XFlushInt () from /usr/local/X11R6/lib/libX11.so.6.0
#9  0xff233f28 in _XFlush () from /usr/local/X11R6/lib/libX11.so.6.0
#10 0xff218204 in XCopyArea () from /usr/local/X11R6/lib/libX11.so.6.0
#11 0x233f8 in CreateStretchXPixmap (dpy=0x3ad70, src=54525956, src_width=64, 
    src_height=65, src_depth=340, dest_width=1332, gc=0x48650) at Graphics.c:82
#12 0x234cc in CreateStretchPixmap (dpy=0x3ad70, src=54525956, 
    src_width=296528, src_height=65, src_depth=24, dest_width=1332, 
    dest_height=18, gc=0x48650) at Graphics.c:117
#13 0x22d5c in CreateBackgroundPixmap (dpy=0x3ad70, win=54525958, width=1332, 
    height=18, colorset=0x3cb90, depth=24, gc=0x48650, is_shape_mask=0)
    at Colorset.c:302
#14 0x1c6e4 in create_manager_window (man_id=249752) at x.c:823
#15 0x16abc in ProcessMessage (type=0, body=0x39a70) at fvwm.c:544
#16 0x16c8c in ReadFvwmPipe () at fvwm.c:601
#17 0x14f2c in main_loop () at FvwmIconMan.c:159
#18 0x15158 in main (argc=0, argv=0xffbef604) at FvwmIconMan.c:294

The pager seems to get a transparent background which is kind of a nice feature but not what I was looking for.

attached is a screen snap with two pagers the one on the left is the second one I started. Yes I did do make cleans everywhere to make sure everything was up to date.
-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous

---

From: Tim Phipps <[email-masked]>
Date: Tue, 17 Aug 1999 13:21:53 +0100

>     src_height=65, src_depth=340, dest_width=1332, gc=0x48650) at Graphics.c:82
                     ^^^^^^^^^^^^^
You lucky sod, fancy having
2239744742177804210557442280568444278121645497234649534899989100963791871180160945380877493271607115776
colors to play with!

--
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: Brad Giaccio <[email-masked]>
Date: Tue, 17 Aug 1999 09:59:25 -0400

> >     src_height=65, src_depth=340, dest_width=1332, gc=0x48650) at Graphics.c:82

No if you notice I only have that many colors when I stretch X pixmaps, I get.  Serioussly I noticedc that so I started stepping through what happens, is both the depth that gets passed in and i for the for loop wind up being optimized to registers.  And when the core gets made it checks its last location for src_depth and it usually happens that it is in i's register.

---

From: Brad Giaccio <[email-masked]>
Date: Wed, 18 Aug 1999 08:24:02 -0400

Well I found my problem, if you have soom good gradient lines using segments you could verify that this doesn't break segmented gradients to badly.

Basically what was happening after to many fprintfs was that the problem was not stricly FvwmIconMan the problem was that FvwmTheme was dumping core on one of my colorsets.  The reason was that memory was getting trashed ant the cummalitve effect finally caught up with me.  This also fixed my problem of IconMan not picking up all the colorsets I had defined.

So the fix just makes sure we don't write more pixels than we asked for.

Index: Graphics.c
===================================================================
RCS file: /home/cvs/fvwm/fvwm/libs/Graphics.c,v
retrieving revision 1.14
diff -u -B -b -r1.14 Graphics.c
--- Graphics.c	1999/08/16 00:07:26	1.14
+++ Graphics.c	1999/08/18 12:23:54
@@ -251,7 +251,7 @@
       free(pixels);
       return NULL;
     }
-    for (j = 0; j < n; ++j)
+    for (j = 0; ((j < n) && ((curpixel + j) < npixels)); ++j)
       pixels[curpixel + j] = p[j];
     perc += clen[i];
     curpixel += n;
--
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: Tim Phipps <[email-masked]>
Date: Wed, 18 Aug 1999 14:37:08 +0100

> Well I found my problem, if you have soom good gradient lines using segments you could verify that this doesn't break segmented gradients to badly.

Nice one.  Do you know if this problem exists in fvwm?  It has an
alloc-non-linear in two places, one in the menus and one in the
buttonstyle.

Cheers,
Tim.

---

From: Brad Giaccio <[email-masked]>
Date: Wed, 18 Aug 1999 10:05:13 -0400

> alloc-non-linear in two places, one in the menus and one in the
 
My guess would be yes, the change to AllocNonLinearGradient happened here,
I don't know what the origional problem was,  Dominik??.

=========
1999-08-14  Dominik Vogt  <[email-masked]>

    * libs/Graphics.c (AllocNonlinearGradient):
    (AllocLinearGradient): fixed gradient colour allocation
==========

The FvwmTheme line that was causing the problem was 
*FvwmThemeColorset 3 gold #515178 DGradient 128 #000000 #909078

unfortunatelly I relinked fvwm with the fixed library so I can't say if a
MenuStyle * MenuFace DGradient 128 #000000 #909078

would have caused a problem or not, but it does look right with the fix.

Brad

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 19 Aug 1999 04:05:56 +0200

> I don't know what the origional problem was,  Dominik??.

The last colour specified for a gradient was never actually used.
Hard to notice with a 100 colour gradient. But if you had a two
colour gradient, say from yellow to blue, the first colour was
yellow and the second was green. The third colour would have been
blue then. Seems that I forgot making sure we don't allocate too
many colours. Could someone check if this is still working?

(Try 'HGradient 2 red green').

Bye

Dominik ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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: Brad Giaccio <[email-masked]>
Date: Thu, 19 Aug 1999 09:48:09 -0400

On Thu, Aug 19, 1999 at 04:05:56AM +0200, Dominik Vogt wrote:

> Hard to notice with a 100 colour gradient. But if you had a two colour
> gradient, say from yellow to blue, the first colour was yellow and the
> second was green. The third colour would have been blue then. Seems
> that I forgot making sure we don't allocate too many colours. Could
> someone check if this is still working?
>

I may be confused here either with or without my patch if I try the
above gradient I get 2 colors #ff0000 #807F00 that are displayed.  Now
are you saying I should get something closer to #00ff00 for the second
displayed color?

---

From: Tim Phipps <[email-masked]>
Date: Thu, 19 Aug 1999 17:28:10 +0100

> are you saying I should get something closer to #00ff00 for the second

I think there is something not quite right with the way gradients are
calculated.

Linear Gradients
================
"Gradient 2 black white" should give two pixels black and white. It
gives black and #777777.

Non-linear gradients
====================
1) I don't think the lengths of the segments should have to add up to
100. It's not impossible to add up the numbers and scale from the total.
2) I'd like to be able to have steps in the gradient. I think this measn
being able to specify a segment length of zero and have that translated
in to a segment length of 1 pixel (maybe 0) e.g. "gradient 1000 3 cyan 1
yellow 0 cyan 1 yellow" would give two ramps of 64 pixels from cyan to
yellow.  The closest you can get that the moment is "gradient 1000 3
cyan 49 yellow 1 cyan 50 yellow" whihch doesn't give a nice sharp line
down the middle but a blur.

I think part of the problem stems from the fact that AllocNonLinear uses
AllocLinear to do each segment.

Cheers,
Tim.

---

From: Brad Giaccio <[email-masked]>
Date: Thu, 19 Aug 1999 13:44:38 -0400

> I think there is something not quite right with the way gradients are

That helped Tim now I'm catching on I guess I just always took the gradient stuff as truth and assumed it all worked.  At the very least you are right we need to avoid using AllocLinear in creating nonlinear gradients.  

As to your point on Linear gradients, the reason it is wrong is that it is going through AllocNonLinear to create the gradient.  So nonlinear gets npixels = 2  start = black end = white.  and it then calls linear with npixels=3 start=black end=white   and it returns an array with three colors in it.
Guess which one is getting chopped off?  

If you give me a couple of minutes I can patch the linear stuff.

Brad

---

From: Brad Giaccio <[email-masked]>
Date: Thu, 19 Aug 1999 14:08:59 -0400

I think I have a fix if you wouldn't mind commenting out 
Graphics.c:243 and trying out your various tests.
I did try HGradient 2 black white and that works as planned.

Index: Graphics.c
===================================================================
RCS file: /home/cvs/fvwm/fvwm/libs/Graphics.c,v
retrieving revision 1.15
diff -u -B -b -r1.15 Graphics.c
--- Graphics.c  1999/08/18 13:33:49     1.15
+++ Graphics.c  1999/08/19 18:07:14
@@ -243,7 +243,7 @@
     if (i == nsegs - 1)
     {
       /* last segment, need to allocate the final colour too. */
-      n++;
+     /*  n++; */
     }
     p = AllocLinearGradient(s_colors[i], s_colors[i + 1], n);
     if (!p)

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 19 Aug 1999 16:23:08 +0200

> are you saying I should get something closer to #00ff00 for the second

Of course. My fix intended the right thing, but I missed taking care
of the total number of colours. Although the percentages may add up
to 100% you may get a few colours less or more than you requested
because of ronding errors. I will look into that.

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 19 Aug 1999 22:52:57 +0200

> I think there is something not quite right with the way gradients are

Ah, we think alike. I have already rewritten the code in this way. The
'100%' limitation was rather silly. I have already removed it and fixed
that damn color allocation.

> down the middle but a blur.

You could now say

  gradient 1000 3 cyan 50000 yellow 1 cyan 50000 yellow

Is that good enough?

> AllocLinear to do each segment.

Not really. The whole logic in the calculations was screwed. The
approach to add up everything and hope that the total is right
simply didn't work.

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 19 Aug 1999 22:58:45 +0200

> I did try HGradient 2 black white and that works as planned.

Forget it :) It's already fixed (=rewritten).

Bye

Dominik ^_^

---

From: Tim Phipps <[email-masked]>
Date: Fri, 20 Aug 1999 14:50:59 +0100

> that damn color allocation.

Excellent stuff. It fixes all my annoyances.

>   gradient 1000 3 cyan 50000 yellow 1 cyan 50000 yellow

Great. I was trying to think of a way to handle "cyan 1 yellow 0 cyan 1
yellow" but couldn't come up with an alogorithm that wasn't horrible.

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 20 Aug 1999 16:11:52 +0200

> yellow" but couldn't come up with an alogorithm that wasn't horrible.

Actually that may be possible too. I didn't try it, but I think
the algorithm already handles that case (by not allocating anything
for emty segments). If it doesn't work it would be only a small
change to handle zero length too.

Bye

Dominik ^_^

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
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]