Bug 20037

Summary: client damage reporting with exa causes window corruption
Product: xorg Reporter: Thomas Hellström <thomas>
Component: Server/GeneralAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: major    
Priority: medium CC: adf.lists, madman2003
Version: git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 17452    
Attachments:
Description Flags
Simple test program that triggers the bug. none

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

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.