Bug 7381

Summary:

Coordinates get wrapped in accelerated line drawing on pixmap

Product:

xorg

Reporter:

Paul Mackerras <paulus>

Component:

Server/Acceleration/XAA

Assignee:

Xorg Project Team <xorg-team>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

high

Keywords:

patch

Version:

7.0.0

Hardware:

All

OS:

Linux (All)

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
Program to draw a line	none
Patch to fix overflows in XAAPolylinesWideSolid	none

Description Paul Mackerras 2006-06-30 20:07:41 UTC

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.

Comment 1 Paul Mackerras 2006-06-30 20:14:23 UTC

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.

Comment 2 Paul Mackerras 2006-07-01 01:13:39 UTC

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.

Comment 3 Keith Packard 2006-07-01 11:15:51 UTC

Thanks, Paul.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.