XCopyArea clip bug

[Maarten Maathuis]

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
>> pixmap.
>
> I saw this reply in the archives:
> http://lists.freedesktop.org/archives/xorg/2009-February/043340.html
> 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
> clipped.)
>
>

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.

Maarten.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clip.patch
Type: application/octet-stream
Size: 624 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20090205/0b95a668/attachment.obj>