Possible bug in Composite extension

[Amir Bukhari]

I have filed a bug in bugzilla describe this issue. you can access it at
this link:
https://bugs.freedesktop.org/show_bug.cgi?id=2230

On Wed, 2005-01-05 at 10:46 -0800, Keith Packard wrote:
> 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
> 
>