pCompositeClip

[Jeremy Huddleston]

Also, using fbFillRegionSolid instead of PolyFillRect gets working results with either drawable (from the pixmap) or pWin->drawable ... I'd expect this because we were using fbFillRegionSolid for this in fbPaintWindow before fbPaintWindow was nuked in favor of miPaintWindow...

I'm confused why results don't seem to depend on which drawable we use here, but it does affect PolyFillRect

	if(solid) {
#if 1
	    fbFillRegionSolid(&pWin->drawable,
			      prgn,
			      0,
			      fbReplicatePixel(fill.pixel,
					       pWin->drawable.bitsPerPixel));
#else
	    fbFillRegionSolid(drawable,
			      prgn,
			      0,
			      fbReplicatePixel(fill.pixel,
					       drawable->bitsPerPixel));
#endif
	    return;
	}



On Apr 18, 2010, at 11:21, Jeremy Huddleston wrote:

> I did a little bit more diving into this, and it looks like the drawable we get from:
>        pixmap = (*pScreen->GetWindowPixmap) ((WindowPtr) drawable);
>        drawable = &pixmap->drawable;
> has some odd (to me) properties:
> 
> 1) The resulting GC operation for PolyFillRect is damagePolyFillRect rather than RootlessPolyFillRect ... why is this not using our RootlessPolyFillRect?
> 2) the drawable is in relative to the window rather than the screen.  Why is this?
> 
> If I offset the drawable's x/y by the appropriate amount, we don't write the valid memory and die in flames.  If I instead offset the clip region by this amount, everything works out fine:
> 
> Note that the correct offset is actually from the passed region, not from the window.
> 
> There are so many coordinate systems involved here that I'm not sure what the correct one should be.  Does this added bit of info help point to a possible underlying cause?  I'm going to start diving into ValidateGC to figure out why pCompositeClip is being set as it is, but I suspect someone out there (Keith?) understands this much better than I do.
> 
>    if(what == PW_BORDER) {
> 	pGC->pCompositeClip->extents.x1 += prgn->extents.x1;
> 	pGC->pCompositeClip->extents.y1 += prgn->extents.y1;
> 	pGC->pCompositeClip->extents.x2 += prgn->extents.x1;
> 	pGC->pCompositeClip->extents.y2 += prgn->extents.y1;
>    }
> 
> 
> On Apr 18, 2010, at 04:14, Jeremy Huddleston wrote:
> 
>> So I've been battling a rather annoying bug rendering borders in XQuartz:
>> 
>> http://xquartz.macosforge.org/trac/ticket/290
>> 
>> Everything works fine when the window is located at the screen origin.  Interestingly, another recent regression also results in some window contents getting clipped as if the clipping bounds were translated to the origin:
>> 
>> https://bugs.freedesktop.org/show_bug.cgi?id=26124
>> 
>> so my assumption is that these two are related.  I've figured out a workaround for the first issue (below) which essentially sets the clipping region in miPaintWindow to the entire screen.  In some runs through, it looks like this clipping region was getting set to (0,0 <window width> x <window height>), and the rects being drawn were in the screen's coordinate system (which is expected).
>> 
>> Now, why would this be happening?
>> 
>> As I did some resizing of the window, I noticed the following:
>> 
>> GC: 0 x:670-870 y:335-535 drawable: 670 335, pWin->drawable: 670 335
>> GC: 0 x:560-874 y:225-556 drawable: 560 225, pWin->drawable: 560 225
>> GC: 1 x:0-333 y:0-377 drawable: 0 0, pWin->drawable: 670 335
>> GC: 0 x:560-893 y:225-580 drawable: 560 225, pWin->drawable: 560 225
>> GC: 1 x:0-333 y:0-377 drawable: 0 0, pWin->drawable: 670 335
>> GC: 0 x:560-893 y:225-580 drawable: 560 225, pWin->drawable: 560 225
>> GC: 0 x:560-910 y:225-598 drawable: 560 225, pWin->drawable: 560 225
>> GC: 0 x:560-910 y:225-598 drawable: 560 225, pWin->drawable: 560 225
>> 
>> ErrorF("GC: %d x:%d-%d y:%d-%d drawable: %d %d, pWin->drawable: %d %d\n", what,
>>      pGC->pCompositeClip->extents.x1, pGC->pCompositeClip->extents.x2,
>>      pGC->pCompositeClip->extents.y1, pGC->pCompositeClip->extents.y2,
>>      drawable->x, drawable->y, pWin->drawable.x, pWin->drawable.y);
>> 
>> The window I was resizing was from border.c in http://xquartz.macosforge.org/trac/ticket/290
>> 
>> Thanks for the help... now it's time for me to sleep...
>> 
>> --Jeremy
>> 
>> diff --git a/mi/miexpose.c b/mi/miexpose.c
>> index 6776064..b43777d 100644
>> --- a/mi/miexpose.c
>> +++ b/mi/miexpose.c
>> @@ -680,6 +680,19 @@ miPaintWindow(WindowPtr pWin, RegionPtr prgn, int what)
>> 	prect->height = pbox->y2 - pbox->y1;
>>    }
>>    prect -= numRects;
>> +    
>> +#ifdef XQUARTZ
>> +    /* Looks like our clipping isn't set right for some reason:
>> +     * http://xquartz.macosforge.org/trac/ticket/290
>> +     */
>> +    if(what == PW_BORDER) {
>> +	pGC->pCompositeClip->extents.x1 = 0;
>> +	pGC->pCompositeClip->extents.y1 = 0;
>> +	pGC->pCompositeClip->extents.x2 = drawable->pScreen->width;
>> +	pGC->pCompositeClip->extents.y2 = drawable->pScreen->height;
>> +    }
>> +#endif
>> +
>>    (*pGC->ops->PolyFillRect)(drawable, pGC, numRects, prect);
>>    xfree(prect);
>> 
>> 
>> _______________________________________________
>> xorg-devel at lists.x.org: X.Org development
>> Archives: http://lists.x.org/archives/xorg-devel
>> Info: http://lists.x.org/mailman/listinfo/xorg-devel
> 
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel