Created attachment 22751 [details] Simple test program that triggers the bug. DRI clients that call DamageAdd when EXA is enabled may cause corruption of windows placed to the right or below the damage area. This appears happen even if all prepare driver hooks return FALSE, that is even without hardware acceleration. The bug is present in the xserver-1.6-branch, but master Commit c35a4be3f895fcf85d84e9044768b96cdae851f8 appears to fix this issue. No side-effects seen.
Fixed in master, commit c35a4be3f895fcf85d84e9044768b96cdae851f8
(In reply to comment #1) > Fixed in master, commit > c35a4be3f895fcf85d84e9044768b96cdae851f8 > Wrong commit ID. The correct one is 5cc67ae94c066dcac78072ad8a819c3b602d8bab
Reopening and marking as blocker for 1.6. Have you verified that cherry-picking just this commit to server-1.6-branch fixes the problem? I think there was already a bug report with similar symptoms, but I can't seem to find it right now.
I find 5cc67ae94c066dcac78072ad8a819c3b602d8bab a strange commit to fix anything, but i should point out this commit existed to fix a performance regression that was only fixed differently (by properly wrapping the GC in fallbacks) one or two commits later in master. Core font rendering needs to be double checked for acceptable performance.
*** Bug 18328 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > Reopening and marking as blocker for 1.6. > > Have you verified that cherry-picking just this commit to server-1.6-branch > fixes the problem? > Yes, it does. I can't immediately see why, though.
(In reply to comment #4) > I find 5cc67ae94c066dcac78072ad8a819c3b602d8bab a strange commit to fix > anything, but i should point out this commit existed to fix a performance > regression that was only fixed differently (by properly wrapping the GC in > fallbacks) one or two commits later in master. Core font rendering needs to be > double checked for acceptable performance. > It may have been a bug in the exa implementation. It might even have been that we're avoiding other EXA problems (migration issues?) with this.
(In reply to comment #7) > It may have been a bug in the exa implementation. That's probably it. > It might even have been that we're avoiding other EXA problems (migration > issues?) with this. Possible, but less likely; together with the additional change in master mentioned in comment #4, the migration behaviour should be more or less the same. (Maarten measured core font rendering to be about the same speed before and after his changes, which seems to confirm this)
I've cherry-picked this commit to the 1.6 branch, marking it as fixed
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.