Bug 37233 - Redrawing in clipped regions damaged
Summary: Redrawing in clipped regions damaged
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: 7.5 (2009.10)
Hardware: x86 (IA32) Linux (All)
: high major
Assignee: Eric Anholt
QA Contact: Xorg Project Team
Depends on: 30528
  Show dependency treegraph
Reported: 2011-05-15 11:00 UTC by thor
Modified: 2011-08-01 04:27 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

screen shot of libreoffice --calc (112.27 KB, image/jpeg)
2011-08-01 04:27 UTC, Toralf Förster
no flags Details

Description thor 2011-05-15 11:00:43 UTC
This bug shows when overlaying windows are moved accross each other, most notably with xpdf and applications using the athena widget system. The symptoms are incorrect rendering and damaged graphics in the regions damaged by moving the window.

This bug is a duplicate of 30528, where, specifically, it has been reported
as "unredrawn borders". This bug persists in release 2.15.0 of the intel driver, but unlike the previous reports, this one includes a patch fixing the problem.

The bug is in uxa/accel.c, around lines 180ff, in uxa_fill_spans() where a test whether the line to be drawn is in the damaged region is incorrect.

			while (nbox--) {
				if (pbox->y1 > fullY1)

				if (pbox->y1 <= fullY1 && pbox->y2 > fullY1 /* bug was here!!!*/ ) {
					partX1 = pbox->x1;
					if (partX1 < fullX1)
						partX1 = fullX1;

					partX2 = pbox->x2;
					if (partX2 > fullX2)
						partX2 = fullX2;

The test for "pbox->y2 > fullY1" was missing here in the marked line.
Comment 1 Eric Anholt 2011-05-31 22:47:01 UTC
Your patch definitely looks correct to me, though it doesn't fix the corruption I see when dragging a gnome-terminal over an xpdf or nedit window under metacity (particularly in the metacity window decorations, though bits of junk also show up in the window contents).

Care to submit a full patch using git format-patch so we can make sure we get the attribution right on your change?
Comment 2 Eric Anholt 2011-05-31 23:53:02 UTC
Scratch that, my testing was just bad.  And, on second thought, I want to delete a bunch of this clipping code since it's way overcomplicated, but getting your simple fix in would still be good because it means we could cherry-pick it back to previous releases.
Comment 3 Eric Anholt 2011-06-05 21:15:29 UTC
Went ahead and pushed the code deletion as-is:

commit e0066e77e026b0dd0daa0c3765473c7d63aa6753
Author: Eric Anholt <eric@anholt.net>
Date:   Tue May 31 23:17:16 2011 -0700

    uxa: Simplify Composite solid acceleration for spans by only clipping once.
    Unlike the previous commit removing this style of code, the code in
    this one was originally wrong, and would fail to clip in the second
    pass of clipping when y was > pbox->y2.
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=37233
    Reviewed-by: Keith Packard <keithp@keithp.com>
Comment 4 Toralf Förster 2011-08-01 04:27:39 UTC
Created attachment 49782 [details]
screen shot of libreoffice --calc


bisecting blames this commit for a curious graphic glitch at a ThinkPad T400 
(integrated intel GM45 graphic) - seen in the attached screen shot.

When I start libeoffice (--calc) and close the empty sheet, few portion 
of the windows still shows the content of the sheet.

This is harmless in the given example but might be more than only annoying for 
sensitive content :

e0066e77e026b0dd0daa0c3765473c7d63aa6753 is the first bad commit

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.