Sorry, but you need to provide all the relevant information here directly; also, one report per bug please.

Of all the reasons to complain, really...
And that's one bug, unless you count that hang too.

So:
xorg-server 1.5.3 with a lot of git patches (Gentoo r1)
xf86-video-ati 6.10.0 (but yesterday git too)
EXA
(may not be relevant) Composite and xcompmgr

Slight display corruption visible in wine's regedit after
expanding and collapsing a few branches in the treeview.

Section "Device"
        Identifier  "open-radeon"
        Driver      "radeon"
        Option          "GARTSize" "64"
        #Option      "AGPMode" "4"
        #Option      "MergedFB" "true"
        Option          "EnablePageFlip" "true"
        Option          "AccelDFS" "true"
        Option          "VGAAccess" "off"
        Option          "DDCMode" "true"
        Option          "AccelMethod" "EXA"
EndSection

Rafał, please attach the screenshot here. It'll make things easier for everyone.

Thanks

Created attachment 22593 [details]
Same screenshot as in wine's bugzilla

(In reply to comment #2)
> Of all the reasons to complain, really...

Very funny... do you have any idea how much time I've wasted chasing information externally that should have been here in the first place? Not to mention that external links tend to stop working after some time.


> xorg-server 1.5.3 with a lot of git patches (Gentoo r1)

How up to date are those patches with EXA in xserver Git?


(In reply to comment #3)
>         Option          "AccelDFS" "true"

Does it happen without this option?

If so, does

    Option "EXAOptimizeMigration" "off"

work around the problem?

If neither of these help, it might be useful to get some information about what kind of rendering operations Wine uses for the affected elements.

(In reply to comment #6)
> How up to date are those patches with EXA in xserver Git?

I'm only missing the devPrivates change, the _X_EXPORT stuff from Paulo and the "NEED_EVENT" clean-up patch. All the other patches that touch exa/ are in our patchset.

And if it's any help, with the same xorg-server, I can't reproduce with the intel driver on an 855GM.

Thanks

Well, bugzillas do reference each other across projects.

And, as I already mentioned, AccelDFS option doesn't seem to make
a difference. EXAOptimizeMigration, however, does. With it off,
problem looks fixed.

On unrelated note: you should consider changing that
automake rule from 'git-log' to 'git log' as those hardlinks
are already moved from PATH and are planned to be removed eventually.

Well, 6.11.0 didn't fix this.
The question here is: as EXAOptimizeMigration is a server option,
maybe this bug should be reassigned to xserver.
Or is this already fixed in xorg-server git and Gentoo needs to
pick up a few more patches ?

(In reply to comment #10)
> Or is this already fixed in xorg-server git and Gentoo needs to
> pick up a few more patches ?

I'm afraid it's unlikely, but if you could try...

An update: no change with xorg-server 1.6.0.

Just to show I still remember:
xorg-server 1.6.1 and xf86-video-ati 6.12.2 - no change.

I'm having a hard time reproducing this with EXA from current upstream xserver Git. Can you try that?

Do you mean "EXA: Handle separate alpha maps properly in Composite fallback, take two" commit ?
Sounds promising, it may be a compositing problem.
I'll try to test it in the near future.

Well, either it's a different commit,
or those fixes are in master only, not in 1.6-branch.
And I'm bit wary of diving into master,
it's hard to tell what needs to be upgraded besides the server
and going into pure git for everything is bit too much.

Sorry for not answering earlier.

Right now I'm on xorg-server 1.7.3
and unless default EXAOptimizeMigration value has changed,
it seems fixed now.

(In reply to comment #17)
> Right now I'm on xorg-server 1.7.3 and unless default EXAOptimizeMigration
> value has changed, it seems fixed now.

It should still/again be enabled by default. If you're in doubt you could try enabling it explicitly and check in the log file that it is recognized.

For now assuming it's fixed, thanks for the followup.