Created attachment 17159 [details] [review] 0001-Report-damage-before-modifying-the-area-not-after.patch Using two cursors (the second of which is SW rendered) can lead artefacts on the screen when moving windows around. Reproducable simply with compiz, current xserver git master, and by creating two cursors to, well, move windows around. I compared SW cursor redrawing with and without a composite manager, the artefacts are created when the cursor rendering restores the previously buffered image in miSpriteRemoveCursor after a call to miSpriteReportDamage. Here's a backtrace: (gdb) bt #0 miSpriteRemoveCursor (pDev=0x88f9c38, pScreen=0x8275790) at misprite.c:887 #1 0x081527ca in miSpriteReportDamage (pDamage=0x829fbe8, pRegion=0xbfc0d228, closure=0x8275790) at misprite.c:172 #2 0x081c0488 in DamageReportDamage (pDamage=0x829fbe8, pDamageRegion=0xbfc0d228) at damage.c:128 #3 0x081c09ba in damageDamageRegion (pDrawable=0x8520018, pRegion=0xbfc0d2b0, clip=0, subWindowMode=-1) at damage.c:308 #4 0x081c5d16 in DamageDamageRegion (pDrawable=0x8520018, pRegion=0xbfc0d2b0) at damage.c:1943 #5 0xb7aa3087 in __glXReportDamage (driDraw=0x8496098, x=0, y=0, rects=0xbfc0d330, num_rects=1, front_buffer=1 '\001', data=0x84b2508) at glxdri.c:813 #6 0xaebaf2b9 in driReportDamage (pdp=0x8496098, pClipRects=0xbfc0d330, numClipRects=1) at ../common/dri_util.c:438 #7 0xaebaf469 in driCopySubBuffer (dPriv=0x8496098, x=441, y=488, w=182, h=146) at ../common/dri_util.c:518 #8 0xb7aa1bcb in __glXDRIdrawableCopySubBuffer (basePrivate=0x84b2508, x=441, y=488, w=182, h=146) at glxdri.c:287 #9 0xb7a8dc8c in __glXDisp_CopySubBufferMESA (cl=0x84b4cac, pc=0x8927190 "i") at glxcmds.c:1631 #10 0xb7a8f168 in __glXDisp_VendorPrivate (cl=0x84b4cac, pc=0x8927184 "\233\020\b") at glxcmds.c:2255 #11 0xb7a941aa in __glXDispatch (client=0x85219a0) at glxext.c:492 #12 0x0808c712 in Dispatch () at dispatch.c:448 #13 0x08071ed4 in main (argc=1, argv=0xbfc0d574, envp=0xbfc0d57c) at main.c:415 Without compiz, a backtrace into miSpriteReportDamage is (gdb) bt #0 miSpriteReportDamage (pDamage=0x829cbe8, pRegion=0xbff9f728, closure=0x8272790) at misprite.c:152 #1 0x081bdcef in DamageReportDamage (pDamage=0x829cbe8, pDamageRegion=0xbff9f728) at damage.c:128 #2 0x081be221 in damageDamageRegion (pDrawable=0x84a74a8, pRegion=0xbff9f788, clip=1, subWindowMode=0) at damage.c:308 #3 0x081be3ed in damageDamageBox (pDrawable=0x84a74a8, pBox=0xbff9f7b8, subWindowMode=0) at damage.c:358 #4 0x081c1c37 in damagePolyFillArc (pDrawable=0x84a74a8, pGC=0x84a7270, nArcs=1, pArcs=0x85b8d74) at damage.c:1325 #5 0x080904da in ProcPolyFillArc (client=0x84a6738) at dispatch.c:1806 #6 0x0808c756 in Dispatch () at dispatch.c:448 #7 0x08071f24 in main (argc=1, argv=0xbff9f964, envp=0xbff9f96c) at main.c:415 The big difference here is that w/o mesa, the damage is reported _before_ the operation occurs, whereas mesa reports it _after_ the operation, leading the server to draw out-dated data when restoring what was behind the cursor. The patch fixes the problem for me so far, but airlied mentioned that this may leave artefacts with delayed rendering.
3D acceleration and SW cursor rendering just don't really mix well; drivers used to force HW cursor with active 3D clients for this reason. In the long run, I think we need to allow the compositing manager to render the cursors somehow.
On Tue, Jun 17, 2008 at 12:24:19AM -0700, bugzilla-daemon@freedesktop.org wrote: > In the long run, I think we need to allow the compositing manager to render the > cursors somehow. davidr had patches around to do just this, actually.
Could this patch be applied until the compositing manager patch has been integrated? The issues still exists
Patch pushed to mesa master, thanks.
> --- Comment #4 from Michel Dänzer <michel@tungstengraphics.com> 2008-08-21 02:23:51 PST --- > Patch pushed to mesa master, thanks. I don't have the logs, but Dave Airlie mentioned on IRC that this patch may cause issues with delayed rendering (i.e. when multiple rendering operations are stacked together), since the damage report may be wrong or incomplete. (This was back when I wrote this patch.) Seems like a lose-lose situation.
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.