Forwarding this EXA bug from a Ubuntu tester: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/270690 [Problem] White "boxes" appear around images when using Compiz under EXA. [Original Report] Using EXA RENDER acceleration in the open source radeon driver, on an rv250 (Mobility 9000), certain transparency elements will get artifacts along the border of the "canvas", for lack of a better word. It's not the border of the actual image, but the border of the entire canvas, i.e. a 32x32 image, of which the non-transparent image is only the center 16x16 square, the artifact would be along the "invisible" 32x32 edges. The artifacts are consistent, in that it's always the same elements that have the problem. Ubuntu Hardy Heron, 8.04 Xserver 1.4, Xorg 7.3 xserver-xorg-video-ati 6.8 The problem has existed since accelerated RENDER has been implemented. Still persists, even in the newer Intrepid Ibex 8.10 xserver and ati drivers. Setting RenderAccel to false, or MigrationHeuristic to greedy makes the problem disappear, as this disables RENDER acceleration. It doesn't seem to affect transparency that's generated by the compositor, but by transparency that's specified by an image. [The chipset is] listed as a FireGL 9000 on spec sheets for my T40p Thinkpad, but shows as a RADEON Mobility 9000 [M9], an rv250 chipset. As for xorg.conf, I can list off the changes I've made to it for the radeon driver: AGPMode 4x DynamicClock on (tried off, too) AccelMethod EXA AccelDFS true (pretty sure I tried off) ColorTiling off (tried on, too) EnablePageFlip off (tried on, too) VGAaccess false (i use radeonfb) SubPixelOrder NONE (supposedly increases composite acceleration speed, according to man) DMAforXv on RenderAccel true Anything not listed means it's at default. MigrationHeuristic defaults to either smart or always (not greedy, anyway) in the intrepid radeon drivers. Anyway, like I said, setting RenderAccel to false, MigrationHeuristic to greedy, or AccelMethod to XAA will not produce the problem, because all of these use software RENDER. I might also note that the transparency edge artifacts change every time the image updates. Easiest way to see results of this is to use cairo-dock with the zoom function (basically, like the mac osx dock when you mouseover). There'll be these white lines along random parts of the border of each element, and every time the image changes size (otherwise, updated) the lines will change position. And finally, I hope this is obvious, but it only happens with a compositor. There wouldn't be accelerated transparency otherwise. [Screenshots] http://launchpadlibrarian.net/18393667/Screenshot-1.png http://launchpadlibrarian.net/18393751/screenshot.png
does: Option "AccelDFS" "False" help?
(In reply to comment #1) > does: > Option "AccelDFS" "False" > help? He said: > AccelDFS true (pretty sure I tried off) And it looks more like filtering artifacts than migration related anyway. If it only happens with scaled (or generally transformed) pictures, it could be related to bug 15334. P.S. Bryce, when forwarding bugs here, please make sure everything is available as attachments here.
Created attachment 20234 [details] lspci -vvnn output
Created attachment 20235 [details] xorg.conf
Created attachment 20236 [details] xorg log
Is this still an issue with xf86-video-ati from git master?
closing due to lack of feedback.
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.