does:
Option "AccelDFS" "False"
or
Option "RenderAccel" "False"
help?

By disabling accelerated DFS _only_, this problem seems to vanish. At least I was not able to reproduce it, and it triggers easily otherwise. I did not try disabling Xrender-acceleration, because AccelDFS=false fixed it. However, disabling DFS-acceleration makes Compiz-desktop slower (more lags, and as far as I'm able to tell, slightly more motion-tearing).

By only disabling Xrender-acceleration (leaving accelerated DFS enabled), the problem does *not* go away. So AccelDFS must be the key.

Disabling Xrender-acceleration actually causes artifacts in Firefox-tabs (immediately visible by switching between them) and I observed persistent leftovers from the resize-highlight-region in Compiz, after having resized a window. Seems things are more stable (and faster) with render-acceleration than without :).

There are actually artifacts on many more GTK-widgets (in Firefox) without render-acceleration. Drop-down boxes are only partly painted after becoming visible as a result of scrolling, but a widget redraw in general fixes things up.

Forget the observation about increased tearing, false alarm. Sometimes my mind plays tricks on me.

*** This bug has been marked as a duplicate of bug 18399 ***

I'm not sure this bug should be marked as duplicate of bug 18399, because this problem still occurs frequently with latest radeon GIT, while bug 18399 does not (at least I am unable to reproduce).

Something like the following always fixes 99% of the corruption issues i'm seeing with radeon:
--- a/src/radeon_exa_funcs.c
+++ b/src/radeon_exa_funcs.c
@@ -401,7 +401,7 @@ FUNC_NAME(RADEONDownloadFromScreen)(PixmapPtr pSrc, int x, int y, int w, int h,
      * blitting the bits to one half while copying them out of the other one and
      * then swapping the halves.
      */
-    if (info->accelDFS && bpp != 24 && RADEONGetDatatypeBpp(bpp, &datatype) &&
+    if (info->accelDFS && bpp != 24 && w>32 && RADEONGetDatatypeBpp(bpp, &datatype) &&
        RADEONGetPixmapOffsetPitch(pSrc, &src_pitch_offset) &&
        (scratch = RADEONCPGetBuffer(pScrn)))
     {


I guess it is obvious why; For small pixmaps things are already used before they are completely there.

In your case is is probably a dupe of bug 18397.

right. That's correct. I even see i made a small comment there before.

(In reply to comment #8)
> Something like the following always fixes 99% of the corruption issues i'm
> seeing with radeon:
> --- a/src/radeon_exa_funcs.c
> +++ b/src/radeon_exa_funcs.c
> @@ -401,7 +401,7 @@ FUNC_NAME(RADEONDownloadFromScreen)(PixmapPtr pSrc, int x,
> int y, int w, int h,
>       * blitting the bits to one half while copying them out of the other one
> and
>       * then swapping the halves.
>       */
> -    if (info->accelDFS && bpp != 24 && RADEONGetDatatypeBpp(bpp, &datatype) &&
> +    if (info->accelDFS && bpp != 24 && w>32 && RADEONGetDatatypeBpp(bpp,
> &datatype) &&
>         RADEONGetPixmapOffsetPitch(pSrc, &src_pitch_offset) &&
>         (scratch = RADEONCPGetBuffer(pScrn)))
>      {
> 
> 
> I guess it is obvious why; For small pixmaps things are already used before
> they are completely there.
> 

Just discovered this. Am running Fedora 12 and was experiencing small pixmap corruption, which then bled into things like corruption in Firefox's places.sqlite (bookmarks) database, via stored favicons that had been corrupted. Grrr.

Hand-applied Danny's patch above to xorg-x11-drv-ati-6.13.0-0.11.20091119git437113124.fc12.src.rpm from the Fedora 12 repository and the corruption issue has been resolved with no apparent decline in stability or performance.

Can no longer duplicate corruption in places where I could always immediately reproduce before (i.e. by loading Slashdot front page and scrolling Firefox up and down past the poll options).