ShadowFB + Composite + RandR + ?
Thomas Winischhofer
thomas at winischhofer.net
Tue Sep 27 11:16:24 PDT 2005
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thomas Winischhofer wrote:
> Keith Packard wrote:
>
>>>On Tue, 2005-09-27 at 10:51 +0200, Thomas Winischhofer wrote:
>>>
>>>>However, if a composite manager is running, xf86SetRootClip(false)
>>>>*does* cause a few calls to pScreen->PaintWindow[Border|Background](),
>>>>which - due to shadowfb - end up in the driver's refresh routine.
>>>
>>>
>>>That's wrong...
>
>
>
> Good to see that you agree :)
>
>
>
>>>>Not only should this IMHO not happen at all (after all,
>>>>setRootClip(false) is supposed to "disable rendering to the screen"),
>>>>the regions (boxes) that are handed to the driver's refresh function
>>>>have illegal coordinates like (-1000, -976), (-1000, -986) and the like.
>>>>Apart from negative values, they sometimes also exceed the valid range
>>>>in both x and y directions.
>>>
>>>
>>>I have no idea why it would do this; I would assume that there's
>>>something broken in the composite wrappers.
>>>
>>>A stack trace from within the offending functions might be illuminating.
>
>
>
> I will try to find out more soon. The whole upper level stuff isn't
> really my area of expertise...
>
> In the meantime, I have analyzed the coordinates: It seems that, if the
> composite manager is running, there is absolutely no clipping done to
> the boxes handed to the refresh handler. If I move a window partly
> outside, the coordinates of the boxes are not limited to the framebuffer
> dimensions.
>
> As a consequence, the following happens here for example:
>
> I run KDE with kicker in "auto-hide"-mode so that it "scrolls" itself
> outside the visible screen whenever the mouse is not over it.
>
> Right after EnableDisableFBAccess(FALSE) and *within* setRootClip(false)
> - so: BEFORE RandR has changed the pScreen structure to the new
> dimensions!!! - I receive
>
> 1) via PaintWindow() the absolute coordinates of the kicker-window(s)
> (it consists of a number of subwindows): My screen is 1280x800, and I
> receive like eg.
>
> x1 x2 y1 y2
> 128 1152 800 847
>
> That's where kicker is in hidden state. (128 and 1152 because it doesn't
> use the whole screen's width.)
>
> 2) later, after all the kicker windows are "redrawn", comes the
> following, again via PaintWindow() (with 5 boxes at once):
>
> x1 x2 y1 y2
> 3 4 435 461
> 95 4 435 461
> 3 4 461 461
> 95 4 461 461
> 3 4 462 461
>
> Except the first one, all are illegal. They seem to relate to my conso?e
> window, which is at the top left screen corner.
>
> A few calls later, a 38-box PaintWindow():
> 4 658 0 1
> 3 658 1 1
> 2 658 2 1
> 1 658 3 1
> 0 658 4 1
>
> and all of the following have y coordinates whose y1 is bigger than y2.
>
> 3) The very last is
>
> 0 1280 0 800
>
> which seems to be the root window.
>
> At this point xf86SetRootClip(FALSE) and EnableDisableFBAccess(FALSE)
> return.
>
> Now RandR sets its new screen dimensions. My example is a 90 degree
> rotation.
>
> At the end, RandR calls EnableDisableFBAccess(TRUE), which leads to a
> xf86SetRootClip(TRUE). This leads to
>
> 1) PaintWindow (1 box):
>
> -1000 -979 -1000 - 986
>
>
> 2) PaintWindow (1 box):
>
> -1000 -978 -1000 - 978
>
> 3) kicker redraw. Kicker doesn't understand that the display is rotated,
> so it still paints itself at 128x801 (which is now near the middle of
> the rotated screen). But that's kicker's fault. Bad RandR signal handler.
>
> 4) Then the following PaintWindow() comes:
>
> 3 4 435 461
> 95 4 435 461
> 3 4 461 461
> 95 4 461 461
> 3 4 462 461
>
> Looks familiar, doesn't it...
>
> 5) Surprise: Now again that 38-box PaintWindow() arrives, with the exact
> same coordinates as above.
>
> Then xf86SetRootClip(TRUE) returns, and so does EnableDisableFBAccess(TRUE).
>
> At this point EXA/XAA re-init their pixmap cache/offscreen memory managers.
>
> Now the screen dimension is 800x1280.
>
> After a few Composite() calls with legal coordinates, bummer....
>
> ShadowPolyFillRect comes along with
>
> x1 x2 y1 y2
> 599 1280 0 800
>
> A few CopyAreas() later, I get a Composite() call with
>
> -1000 -979 -1000 -986
>
> And again kicker (which I assume from the coords):
>
> 128 1152 800 847
>
> and lots more calls with such coordinates.
>
> (Why is x2 1152, when the screen is only 800 in width? Shouldn't that be
> clipped by anybody?)
>
> After that, another Composite():
>
> 1031 1053 813 835
>
> seems to relate to kicker's window as well (which, as we know, still at
> 800-847 on the y axis)
>
> Now I move my console window beyond the left edge of the screen:
>
> I get a few PaintWindow() calls with coordinates like
>
> -308 332 400 415
>
> I worked-around this now by checking my refresh box, but something is
> really odd here.
>
> Perhaps I should mention that everything looks entirel ok on the rotated
> screen - no graphics distortions whatsoever; except, of course, kicker
> which is located right in the middle.
PaintWindow and CopyArea and others (noticed especially PolyFillRect)
are called even in case the composite manager has redirected a window.
Confirmed this by ignoring calls to these functions - and still the
screen looks identical. Plus, everything is much faster...
I don't know where the bad coordinates come from yet - but I suspect
that these come from the calcuations in shadow.c itself, as it copies,
translates and intersects the region with the "DDXPointRec" it gets.
This might go wrong in case the window is redirected.
I now need a simple way to find out if the pWin is redirected or not, or
if the drawable is not the frontbuffer. (And for some reason I don't
understand, Window->redirectDraw is not set...)
Thomas
- --
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net *** http://www.winischhofer.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDOYx3zydIRAktyUcRAhTqAJ0WgFFVB1sv13dmbSxIHGP9Uwxe7ACdF46t
8oIeee+LIOCx3WK9SIR/E4I=
=64rL
-----END PGP SIGNATURE-----
More information about the xorg
mailing list