Subject: Re: DGradient - One mo' bug

From: Bob Woodside <[email-masked]>
Date: Mon, 1 Feb 1999 09:22:11 -0500 (EST)

Dominik Vogt <[email-masked]> wrote:
> On Sun, Jan 31, 1999 at 10:18:39PM -0500, Bob Woodside wrote:
> > -	      XDrawLine(dpy, mr->w, Scr.TransMaskGC, (int)(i*ds), mr->height,
> > -			mr->width, i);
> > +/*  RBW  --  Test - try arbitrarily subtracting 1 from x values... */
> > +	      XDrawLine(dpy, mr->w, Scr.TransMaskGC, ((int)(i*ds) - 1), mr->height,
> > +			(mr->width - 1), i);                            ^^^^^^^^^^
>                         ^^^^^^^^^^^^^^^ <-- OK                          WRONG

	Well, I believe the (int)(i*ds) - 1) is wrong also (deliberately
so - as I said, I just wanted to see what happened if I moved the line
one pixel to the left, and was surprised that it didn't cause a different
mis-drawing). Only the rightmost end point should have been moved to the
left.

> These ones seem to be bugs. If the menu is n times m
> pixels wide/high, the biggest valid x/y values are n-1 and
> m-1. I.e. x = mr->width and y = mr->height are not inside the
> menu. Wasn't there some discussions recently if the end points
> of a line are drawn (XDrawLine)? The same applies to other
> parts of the diagonal gradient code.

	I should think so. But this is the only area where I saw the
problem occurring, so it's the only one I tinkered with. I'm really
curious whether anyone else can duplicate the problem.

> If this solves the problem in this situation there must be
> a bug in the compiler or some math library or your X server.

	That's conceivable. I'm using egcs 1.0.2 on a Linux system
with the AcceleratedX 4.1 X server (which has always seemed quite
solid). This is the only machine I have access to that I can test
this stuff with. The Sun box at work is one of those infernal 8-bit-
only mongrels, so any gradient decorations are pretty much out.

> I dont understand these lines:
> 
>   if( i % dc == 0 )
>     XSetForeground(dpy, Scr.TransMaskGC,
>                    ms->look.face.u.grad.pixels[cindex++]);
> 
> What are the circumstances under which the cindex is increased
> (in human readable language)?

	As I said before, I don't pretend to understand any of
the menu code. Umm...who wrote this part?

- Bob

--
Visit the official FVWM web page at <URL:http://fvwm.math.uh.edu/>.
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: Bob Woodside <[email-masked]>
Date: Mon, 1 Feb 1999 10:56:11 -0500 (EST)

> mis-drawing). Only the rightmost end point should have been moved to the

	Hmm...I was forgetting the odd line of pixels in the middle
where the background showed through. Maybe the move of both end
points was the right thing.

- Bob

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 1 Feb 1999 17:30:10 +0100

> only mongrels, so any gradient decorations are pretty much out.

Could you try the same with gcc, just to make sure?

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://fvwm.math.uh.edu/>.
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: Dominik Vogt <[email-masked]>
Date: Mon, 1 Feb 1999 17:31:24 +0100

> points was the right thing.

Well, I think I can decide if this was right or wrong by
checking the code, but it doesn't explain the vertical
lines on the root window.

Bye

Dominik

---

From: Bob Woodside <[email-masked]>
Date: Mon, 1 Feb 1999 14:10:21 -0500 (EST)

> Could you try the same with gcc, just to make sure?

	Not quickly, since I don't have a stock (non-egcs) gcc on
this machine anymore. I'd have to install one.

	However, for our immediate purposes, the change that Tim
just posted corrects the problem, so I'd vote that we go with it
unless anyone sees any reason for skepticism. It also seems a mite
quicker and smoother on my slo-o-o-w 133 MHz machine..

	When I have a little free time, however, I would like to try
a stock gcc (and a newer egcs) with the old code, just to see what
we can see.

- Bob