Subject: DGradient - One mo' bug

From: Bob Woodside <[email-masked]>
Date: Sat, 30 Jan 1999 21:38:29 -0500 (EST)

I have to confess I've not been following the menu bug threads
very closely, but since the known problems seem to be resolved, I
thought I'd try to do a little testing. Here's one that doesn't seem
to have been reported before (though I have noticed it before - I just
thought it was probably related to the other bugs).

	It's difficult to describe, so I put a screen shot at

	http://www.pcnet.com/~proteus/Fvwm/Screen.jpg

since it's a little large to spam the whole mailing list with.

	First, here are the pertinent definitions from my .fvwm2rc:

MenuStyle "*" FVWM, Hilight3DThick, Foreground black, Background Red4
MenuStyle * MenuFace DGradient 128 2 RoyalBlue 50 LightSkyBlue 50 MidnightBlue

	This is based on the setup Danek Duvall originally reported a
problem with, just not so grey. The first MenuStyle line is there to lay
in a strongly contrasting background so the problem shows up more clearly.

	It looks like a rounding error creeps in somewhere in the calc-
ulations for where a line should be drawn. The result is a diagonal line
of missed pixels where the background shows through, and a spurious ver-
tical line on the right side of the menu where the line drawing overshoots
the edge of the menu. Worse, when the menu pops down, these artifacts are
left on the screen.

	This only occurs on some menus. The screen shot shows one of the
menus that behaves this way, plus the artifacts from a couple of previous
poppings-up of that same menu.

- 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: [email-masked] (Paul D. Smith)
Date: 31 Jan 1999 11:15:28 -0500

%% Bob Woodside <[email-masked]> writes:

  bw> 	It looks like a rounding error creeps in somewhere in the calc-
  bw> ulations for where a line should be drawn. The result is a
  bw> diagonal line of missed pixels where the background shows through,
  bw> and a spurious ver- tical line on the right side of the menu where
  bw> the line drawing overshoots the edge of the menu. Worse, when the
  bw> menu pops down, these artifacts are left on the screen.

Does someone want to look at this before I spin 2.1.11?  Or should we
just go ahead?

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
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: Dan Espen <[email-masked]>
Date: Sun, 31 Jan 1999 14:05:42 -0500

> poppings-up of that same menu.

  I wish I hadn't looked at your screen shots.  I simply must get a 24
bit color system.

  I'm not sure if this is the last menu diagonal gradient problem, but
it looks bad to me. I vote for holding the presses to  see if there is
a simple fix...not that I'm volunteering.

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
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: Sun, 31 Jan 1999 22:18:39 -0500 (EST)

> a simple fix...not that I'm volunteering.

	I'd second that vote.

	I did a little playing around with the menu code, where I'm
definitely as rank a novice as they come. The only menus that exhibit
strange behavior are DGradient, and taller than they are wide, so I
tried arbitrarily adjusting the x values for the XDrawLine that's
done in this case one to the left, just to see what it would look
like, and the behavior went away. I expected to see something else
wrong happen, presumably on the other side, but it didn't.

	Now, I don't claim to understand why this works, because I
don't really understand why it was misbehaving before; I haven't had
time to understand the menu code properly. I'd appreciate it if some-
one who's familiar with it would take a look at it. I'm sure the fix
is this simple, but I'm not sure that this is necessarily it.

	This is what I did:

--- menus.c	Sun Jan 31 21:44:00 1999
+++ menus-patched.c	Sun Jan 31 21:43:35 1999
@@ -2098,8 +2098,9 @@
 	      if( i % dc == 0 )
 		XSetForeground(dpy, Scr.TransMaskGC,
 			       ms->look.face.u.grad.pixels[cindex++]);
-	      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);
 	    }
 	  }
         }

- Bob

---

From: Jay <[email-masked]>
Date: Sun, 31 Jan 1999 23:59:04 -0500 (EST)

> a simple fix...not that I'm volunteering.

	I noticed this behavior when I was playing with the gradients.  I
assumed that it was something that I caused in my test code... but
apparantly not.  I was able to get rid of the 'missed pixels' on the
menu by setting the 'line-width' of the GC to more than 1 (I think I had
it set to 3)  I don't know about the stuff left over though.. 

Jay