XCopyArea clip bug
madman2003 at gmail.com
Thu Feb 5 10:02:35 PST 2009
On Wed, Feb 4, 2009 at 10:56 PM, Alexander Larsson <alexl at redhat.com> wrote:
> On Wed, 2009-02-04 at 14:46 +0100, Alexander Larsson wrote:
>> On Wed, 2009-02-04 at 13:38 +0100, Alexander Larsson wrote:
>> > I found what I think is a bug in XCopyArea.
>> > If you copy a pixmap to a window and some of the copied area is outside
>> > the pixmap then that area in the destination window is cleared to the
>> > background color (and possibly graphics exposes are sent).
>> > If the GC has a clip region set so that the destination area that would
>> > contain data from outside the pixmap is clipped out, then I would expect
>> > it to not be cleared.
>> > However, that is not the case right now, even the clipped out area has
>> > the destination cleared to the window background.
>> > I'm attaching an xlib example.
>> Oh, the same thing happens if the source is another window and not a
> I saw this reply in the archives:
> But i don't see in in my inbox, dunno what happened to it.
> Anyway, the screenshot in that mail is correct. (The red part is the
> background set when copying from an obscured source, and its correctly
> clipped so its only visible in the left half of the window. When I run
> it I see red in the right half, while the green part is correctly
This is the (xserver) patch i used to achieve this, someone needs to
ack the change obviously.
miComputeCompositeClip also uses clientClip as a region when !=
CT_NONE, but there are more types.
/* clientClipType field in GC */
#define CT_NONE 0
#define CT_PIXMAP 1
#define CT_REGION 2
#define CT_UNSORTED 6
#define CT_YSORTED 10
#define CT_YXSORTED 14
#define CT_YXBANDED 18
So either miCompositeClip is wrong, or i'm misunderstanding the
situation. Especially CT_PIXMAP is certainly not a region.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 624 bytes
Desc: not available
More information about the xorg