Yes, that works too (presumably because pPicture->clipOrigin.x/y always = 0 in my case)."Kim Woelders" <[email protected]> writes:Commit 128cd03eecacc6d5c5903d59a11966dcf3697bf1 causes trouble with clip regions in the e16 WM composite manager (e.g. during fade-out).This marks the second recorded use of source clipping in the history of the Render extension.The problems are fixed by attached patch. Not sure if this is the proper solution though...The intent of this code is to shift the client clip into destination coordinates, then clip against it. Translating by clipOrigin.x/y converts from region coordinates to source coordinates, and dx/dy is supposed to bring it into destination coordinates. The problem with the commit I think is that I was thinking of dx/dy as the amount the destination is shifted, when it actually is how much the source is shifted. If so, the real fix would be:@@ -318,14 +318,14 @@ miClipPictureSrc (RegionPtr pRegion, Bool result; pixman_region_translate ( pPicture->clientClip, - pPicture->clipOrigin.x - dx, - pPicture->clipOrigin.y - dy); + dx - pPicture->clipOrigin.x, + dy - pPicture->clipOrigin.y);+ pPicture->clipOrigin.x + dx, + pPicture->clipOrigin.y + dy, and a similar correction after the intersection.
New patch attached.
I'd be interested in whether the same bug exists with the vesa driver (or another unaccelerated one).
I tried the vesa driver but get only a mostly black screen. /Kim
bin65dAvgiuKL.bin
Description: Binary data
_______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
