|Summary:||client damage reporting with exa causes window corruption|
|Product:||xorg||Reporter:||Thomas Hellström <thomas>|
|Component:||Server/General||Assignee:||Xorg Project Team <xorg-team>|
|Status:||RESOLVED FIXED||QA Contact:||Xorg Project Team <xorg-team>|
|i915 platform:||i915 features:|
|Bug Depends on:|
Description Thomas Hellström 2009-02-10 07:04:24 UTC
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.
Comment 1 Thomas Hellström 2009-02-10 07:05:12 UTC
Fixed in master, commit c35a4be3f895fcf85d84e9044768b96cdae851f8
Comment 2 Thomas Hellström 2009-02-10 07:14:41 UTC
(In reply to comment #1) > Fixed in master, commit > c35a4be3f895fcf85d84e9044768b96cdae851f8 > Wrong commit ID. The correct one is 5cc67ae94c066dcac78072ad8a819c3b602d8bab
Comment 3 Michel Dänzer 2009-02-10 09:09:09 UTC
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.
Comment 4 Maarten Maathuis 2009-02-10 10:26:24 UTC
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.
Comment 5 Michel Dänzer 2009-02-11 04:01:35 UTC
*** Bug 18328 has been marked as a duplicate of this bug. ***
Comment 6 Thomas Hellstrom 2009-02-11 05:41:31 UTC
(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.
Comment 7 Thomas Hellstrom 2009-02-11 05:44:44 UTC
(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.
Comment 8 Michel Dänzer 2009-02-11 05:52:56 UTC
(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)
Comment 9 Keith Packard 2009-02-25 11:51:24 UTC
I've cherry-picked this commit to the 1.6 branch, marking it as fixed