Possible bug in Composite extension
Amir Bukhari
ufz6 at rz.uni-karlsruhe.de
Wed Jan 5 11:14:27 PST 2005
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.
I have tried it now and it work very good now. I have seen this line but
don't understand what it mean (oldpt.x != x || oldpt.y != y). DDX layer
is complex to understand ;-).
Thanks,
-Amir
More information about the xorg
mailing list