Bug 7381 - Coordinates get wrapped in accelerated line drawing on pixmap
Summary: Coordinates get wrapped in accelerated line drawing on pixmap
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Acceleration/XAA (show other bugs)
Version: 7.0.0
Hardware: All Linux (All)
: high normal
Assignee: Xorg Project Team
QA Contact:
URL:
Whiteboard:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2006-06-30 20:07 UTC by Paul Mackerras
Modified: 2006-07-01 11:15 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Program to draw a line (1.67 KB, text/plain)
2006-06-30 20:14 UTC, Paul Mackerras
no flags Details
Patch to fix overflows in XAAPolylinesWideSolid (909 bytes, patch)
2006-07-01 01:13 UTC, Paul Mackerras
no flags Details | Splinter Review

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.