Comment 3 for bug 270690

Not on my linux machine at the moment (at work, and the machine is in standby, wireless internet no less, so no remote) so I can't get a screenshot. I will do it when I get back.

I can however, say that it's 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, as I assume that's what you're looking for.
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.