Summary: | cairo git rendering corruption | ||
---|---|---|---|
Product: | cairo | Reporter: | Michal Suchanek <hramrach> |
Component: | general | Assignee: | Carl Worth <cworth> |
Status: | RESOLVED DUPLICATE | QA Contact: | cairo-bugs mailing list <cairo-bugs> |
Severity: | normal | ||
Priority: | medium | CC: | hramrach |
Version: | 1.10.3 | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
See Also: | https://bugzilla.mozilla.org/show_bug.cgi?id=715658 | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
corrupted text. Note that some shows the wrong text completely
dmesg log from Ubuntu 'stable' X server - issue remains the same |
The corruption in Firefox is really odd. Some pages (usually somewhat complex) , others not (or not so often). It's often possible to see the page rendered (mostly) correctly for a moment and it only corrupts afterwards, eg. on scrolling. Using firefox 3.6, evince 3. please attach your xorg log and dmesg output. Created attachment 54442 [details]
dmesg
Created attachment 54443 [details]
log from Ubuntu 'stable' X server - issue remains the same
Is this a regression? E.g. does it also happen with 6.14.2 or some even older snapshot? If not, can you bisect? This is hard to tell. On the e-450 the corruption is present with the earliest driver I could get working. On redwood the corruption happens only rarely but as far as I remember ever since I got the card which is again since it got supported. With the r300 card the corruption only happens recently which besides some upgrades coincides with turning off vline waits which might put more load on the card or cause races that would not happen otherwise. It is not reproducible reliably, however, so not something bisectable. I tried experimenting on the e-450 which shows most corruption and found that running firefox causes the corruption (in firefox and elsewhere in gtk). When firefox is closed corruption ceases immediately on next redraw. gtk seems to redraw every element on mouseover so wiggling the mouse pointer over a treeview or a pulldown menu causes a lot of drawing I would guess. The corruption is visually very similar to what I see on the r300 so I guess it's something caused by the driver and the way gtk is drawing, not the hardware. There are pieces of text which are skewed, show garbage or different text in the text color, show a blob in text color approximately the size of the text or less often complete garbage and pieces of different textures. The corruption lasts until redraw. Another way to get the corruption is to configure a lot of applets in avant window navigator. I tried to boot an openSUSE GNOME live CD on an e-350 and it was free of corruption initially. However, opening cover links from addons.mozilla.org, wikipedia.org and wikinews (over 100 tabs total) gives reliable temporary corruption in gtk menus (that is the menu is shown corrupted and redrawn immediately). It seems openSUSE uses some different GTK build because the menus are typically corrupted whole, not per item as on Debian/Ubuntu. (In reply to comment #6) > With the r300 card the corruption only happens recently which besides some > upgrades coincides with turning off vline waits which might put more load on > the card or cause races that would not happen otherwise. I think it's more likely related to 'some upgrades'. > [...] reliable temporary corruption in gtk menus (that is the menu is shown > corrupted and redrawn immediately). That sounds like a well-known regression in the xserver Composite layer, which has been fixed upstream. You have to be careful not to mix up different issues. It's hard to tell if the problem is the same or different. Still I can easily reproduce the corruption on a Fedore 16 live CD running on e-350 system. I install avant-window-navigator, kill gconfd-2 to allow avant to start, and run it. In avant preferences I set smallest icon size, find the system monitor plugin (near the top of plugin lists), and add system monitors until the panel expands across whole bottom of the screen. Clicking a system monitor applet now shows a corrupted window with process information. hmm, the issue with awn on Fedora is wrong transparency. Although it looks like corruption it is deterministic and happens always with the awn version in Fedora. This is clearly a cairo issue. Downgrading cairo I no longer get corruption in awn but get the wrong transparency instead. broken 1.11.3+git20111211.8025fcc4-0ubuntu0ricotz~oneiric0 broken differently 1.10.2-6ubuntu3 Could you test if this was introduced in cairo commit af9fbd176b? (That's what git bisect points at in bug 43764) The right question is whether you observe the same corruption with the vesa driver, or on nvidia, or etc... It did not happen with shadowfb when I downgraded to radeon version that no longer supported the hardware so I guess it's that bug. *** This bug has been marked as a duplicate of bug 47266 *** |
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.
Created attachment 54441 [details] corrupted text. Note that some shows the wrong text completely I experience wholesale corruption on 00:01.0 VGA compatible controller [0300]: ATI Technologies Inc Device [1002:9806] Linux (Ubuntu) 3.2.0-4-generic xserver-xorg-core 2:1.11.2.902+git20111209+server-1 xserver-xorg-video-radeon 1:6.14.99+git20111212.aacbd629-[ 12.711129] [drm] initializing kernel modesetting (PALM 0x1002:0x9806 0x1043:0x84E7). [ 12.711246] [drm] register mmio base: 0xFEB00000 [ 12.711249] [drm] register mmio size: 262144 [ 12.711412] ATOM BIOS: Ontario The attached screenshot shows typical issue - wholesale corruption in GMail. Amusingly, taking a screenshot does not make the thing go away, it just changes which text is corrupted. On Redwood I get occasionally minor corruption in Firefox. On r300 x1600-ish I get similar effects since I disabled vline waits, occasionally. Not sure this is related (either to the vline waits or the r600 issue). The corruption on r300 happens sometimes in Evince or gkrellm (or maybe Firefox), not in terminals. I did not try re-enabling the vline waits or downgrading X because it's hard to tell if the issue is present or not.