Possible bug in Composite extension

[Keith Packard]

Around 12 o'clock on Jan 5, Amir Bukhari wrote:

> I have made a modification to compReallocPixmap, so that it copy
> reasonable pixel from the old pixmap to new pixmap.

Composite already has two existing mechanisms to try and get this right, 
and yet still things remain broken.  The server will call CopyWindow to 
capture the old bits when they move, and Composite already copies data 
from the parent into the new pixmap so that backgroundNone works correctly 
in a simple 2D compositing environment.

Because of the effect of bitGravity, I think we will need some help from 
DIX to know what the right bits to copy are.

If you look at miSlideAndSize window, you'll see a special case that 
doesn't call the CopyWindow proc for bits which 'haven't moved' on the 
screen:

        if (oldpt.x != x || oldpt.y != y)
            (*pWin->drawable.pScreen->CopyWindow)(pWin, oldpt, gravitate[g]);


I suggest that just changing that to *always* call in the case of a
redirected window might be the right solution here:

        if (oldpt.x != x || oldpt.y != y
#ifdef COMPOSITE
	    || pWin->redirectDraw
#endif
           )
            (*pWin->drawable.pScreen->CopyWindow)(pWin, oldpt, gravitate[g]);

Could you give this a try in your environment?  The existing copy from 
parent already solves this problem in a simple 2D environment, so the bug
isn't visible to me.

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20050105/e7ee2530/attachment.pgp>