When drawing a line on a pixmap, Y coordinate values of around 30000 or so get
wrapped to small or negative values, causing lines to be drawn wrongly. This
bug causes the lines in gitk's graph display to be drawn wrongly sometimes.
However, it is not a gitk bug nor a Tk bug; I have an 88-line C program that
uses only Xlib calls that demonstrates the problem.
I have tried this little program on x86 and powerpc systems, and all show the
problem. I have tried this on machines with nVidia (GeForce 6600), Radeon 9600,
and Rage 128 video cards, and all of them show the problem. Disabling
acceleration (with Option "accel" "false" in the xorg.conf file) makes the
problem go away.
Created attachment 6087 [details]
Program to draw a line
This program draws a line on a pixmap and then copies the pixmap to a window.
If the bug is triggered, the line will be a V shape, and will not meet the
bottom edge of the window. The line should go from top to bottom of the window
with a slanted segment in the middle.
If you give an argument to the program, it is taken as the Y coordinate of the
first point in the line. Interestingly, different systems have different
thresholds for this value for showing the bug. Any value up to 32767 *should*
work correctly, but one machine I tried fails for Y >= 29690, another for Y >=
30366, and so on.
Created attachment 6088 [details] [review]
Patch to fix overflows in XAAPolylinesWideSolid
OK, I found it. With this patch my test program no longer fails.
XAAPolylinesWideSolid was adding the drawable origin onto each element in the
pPts array. Since the values got stored back into the pPts array, they got
truncated to 16 bits, causing the overflow I saw. This patch avoids storing
the coords back into the pPts array (and actually reduces the size of the code
too :). Now the 32-bit sum of coords + origin doesn't get truncated to 16
bits, and the problem is solved.