On Wed, Jul 11, 2012 at 4:11 AM, Pierre Ossman wrote: > On Tue, 10 Jul 2012 23:41:55 -0400 > Brian Hinz wrote: > > > > > I've been trying to trace back the source of the PolyFillRects and they > > definitely come from miHandleValidateExposures in mi/miwindow.c -> > > miPaintWindow in mi/miexpose.c and then the PolyFillRect hook should be > > called from miPaintWindow. At the point where miPaintWindow should be > > calling the hook function, the rectangles are correct, but then the > > xRectangle that gets evaluated in vncHooksPolyFillRect is not the same. > > Sometimes vncHooksPolyFillRect is not even called after miPaintWindow at > > all... I'm utterly confused as to how this could be happening, any > chance > > someone can take a peek and see if you can make some sense of it? > > > > I'm messing around in Xvnc for other reasons, so maybe I can have a > quick look. Got a good test case?
Hi Pierre,
Just starting the fluxbox window manager makes for a decent test case
because there are a couple of rectangles that are always drawn at the same
spot (for a given resolution). I've attached a screen shot of the desktop
showing the two rectangles around and inside the task bar at the bottom of
the screen (these borders aren't drawn initially, I had to request a screen
refresh from the client). Here is the output of some debug statements that
I put into miHandleValidateExposures, miPaintWindow, and
vncHooksPolyFillRect that I expected to show the progression of the borders:
...
miPaintWindow called from miHandleValidateExposures:
RegionNumRects(&val->after.borderExposed) = 4
(&val->after.borderExposed)->extents.x1 = 436
(&val->after.borderExposed)->extents.y1 = 575
(&val->after.borderExposed)->extents.x2 = 940
(&val->after.borderExposed)->extents.y2 = 598
miPaintWindow:
RegionNumRects(prgn) = 4
prgn->extents.x1 = 436
prgn->extents.y1 = 575
prgn->extents.x2 = 940
prgn->extents.y2 = 598
vncHooksPolyFillRect:
nrects = 1
rects->x = 0
rects->y = 0
rects->width = 502
rects->height = 21
vncHooksPolyFillRect:
nrects = 1
regRects[0].x = 574
regRects[0].y = 576
regRects[0].width = 0
regRects[0].height = 0
miPaintWindow:
RegionNumRects(prgn) = 0
prgn->extents.x1 = 0
prgn->extents.y1 = 0
prgn->extents.x2 = 0
prgn->extents.y2 = 0
miPaintWindow:
...
This particular output appears to be the inner border on my 1280x600
desktop. The two print statements from vncHooksPolyFillRect are both from
the same iteration. Notice how nrects goes from 4 to 1 and the x, y, width
& height change into something more like a line? It almost seems like the
data that's being passed to vncHooksPolyFillRect is the kind of data that
should be destined for Polylines...?
Another thing that I've noticed is that a lot of 0 rect regions are ending
up in miPaintWindow. I don't think they make it through to
vncHooksPolyFillRect because of this statement in miPaintWindow:
...
prect = malloc(RegionNumRects(prgn) * sizeof(xRectangle));
if (!prect)
return;
...
vncHooksFillRect seems to be equipped to deal with this case, however even
if that were to happen the hook returns without adding anything to the
server's changed region (of course what the heck should be added anyway?):
...
if (nrects == 0) {
(*pGC->ops->PolyFillRect) (pDrawable, pGC, nrects, rects);
return;
}
...
Hopefully this isn't too much random data, I'm just trying to wrap up as
much as I can all at once. Thanks for taking a
look.
-brian
<<attachment: fluxbox-windowborders.png>>
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
