Bug 46792 - Corruption of webpages (firefox) and window content (gimp)
Summary: Corruption of webpages (firefox) and window content (gimp)
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Chris Wilson
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-29 11:56 UTC by Da Fox
Modified: 2012-03-02 13:31 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Da Fox 2012-02-29 11:56:55 UTC
While browsing I've noticed occasional image corruption in firefox, usually (seemingly) in the background of the website. However until today I did not find a website which reproducibly caused the issue. Today I found the following websites where I reproducibly see corruption:
http://groups.google.com/group/managerial-policy-spring2012/browse_frm/thread/3912921e6d12616a
and
http://en.zimagez.com/

In the first website (the google groups page) the comments area in the center can become corrupted (black, confirmed by 'brot' on IRC: http://share.minad.de/dl.php?f=26AZ.png) or, more interestingly, completely garbled: http://en.zimagez.com/zimage/snacorruption.php . To cause the corruption, open the site (in firefox) and try to interact with the center comment area (scroll, select text, select all, change window size, etc).

The second site sometimes shows the corruption on the main screen (logging in not required) while resizing, or when returning to the firefox window/tab containing the site after switching windows and/or workspaces (in xfce). 

Other than in websites, corruption can also be observed when working with the Gimp image editor as follows: use the perspective (or any other tool, presumably) to 'paint' something (the layer) outside of the canvas. (there is no need to apply the transformation). Then cancel the transformation (by pressing cancel on the dialog or hitting 'esc'). This looks like this: http://share.minad.de/dl.php?f=22qG.png (image again kindly provided by 'brot').



My hardware is a Dell XPS 15 (L502x) laptop with:
00:02.0 VGA compatible controller: Intel Corporation Device 0116 (rev 09)
[    13.803] (II) intel(0): Integrated Graphics Chipset: Intel(R) Sandybridge
Mobile (GT2)

Software versions:
Mesa: 15e60d9976f82174afeca1d026f566cb8aea5104
xf86-video-intel: a3c398a6731874ba47e0a46bbd42bf9378e12ab8 (with sna).
x11-base/xorg-server-1.11.2-r2 (gentoo)
libdrm: 783db34f6d8aded019b005a957fed1b91fd67c7c
dri2proto: 7fd18b15646a62bd82a4eb0eca60a34c1731813d
Comment 1 Chris Wilson 2012-02-29 14:28:09 UTC
Looks similar to a bug picked up by the cairo test suite (unsurprising considering its the graphic library used here).
Comment 2 Chris Wilson 2012-03-02 02:04:10 UTC
Can you please update and retest with

commit f039ccf9587eb07528034c3247a6e700c87a5500
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Mar 2 09:47:10 2012 +0000

    sna: Be careful not to discard the clear operation for move-region-to-cpu
    
    When moving only a region to the CPU and we detect a pending clear, we
    transform the operation into a move whole pixmap. In such situations, we
    only have a partial damage area and so need to or in MOVE_READ to
    prevent the pending clear of the whole pixmap from being discarded.
    
    References: https://bugs.freedesktop.org/show_bug.cgi?id=46792
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Thanks.
Comment 3 Chris Wilson 2012-03-02 10:47:15 UTC
From similar reports, I think that did the trick...
Comment 4 Da Fox 2012-03-02 13:31:22 UTC
(In reply to comment #3)
> From similar reports, I think that did the trick...

I tried with 866a61a2590f0c5ae6592a13d4e3de3e68f5e373, and both firefox and the gimp don't show any corruption, so I'm inclined to agree :)


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.