[PATCH resend 3/3] CreateRootWindow: Set root windows' drawable.x/y to -pScreen->x/y.

[Jamey Sharp]

On Wed, Sep 28, 2011 at 03:46:08PM -0700, Aaron Plattner wrote:
> This breaks rendering to the root window.  For example, run "xsetroot
> -solid green"  Part of the rendering is clipped away on one of the
> screens.  E.g., on my setup with a 1024x768 screen and a 1920x1080
> screen to the right of it, only the leftmost 896 pixels of the right
> screen are rendered because its root window extends from column -1024
> to 895, while its borderClip goes from 0 to 1919:

Wow, that was hard to debug, and the borderClip was a red herring.
First, drawing directly to the root window worked fine; all that broke
was changing the window's background tile and then doing ClearArea.
Changing the background even worked if you forced the window to be
re-exposed afterwards, such as by moving another window around over it.

I found xfireworks to be a great test case. (And it's so pretty!)
"xfireworks -direct-draw" renders directly to the root window, and works
fine. "xfireworks -no-direct-draw" renders to a pixmap, sets that pixmap
as the root window's background, and then calls XClearWindow to get the
background repainted. That fails the same way as xsetroot.

This additional patch fixes it for me (it's amended into my
review-pending branch if you want to try it):

diff --git a/Xext/panoramiXprocs.c b/Xext/panoramiXprocs.c
index 9bd63f6..306d956 100644
--- a/Xext/panoramiXprocs.c
+++ b/Xext/panoramiXprocs.c
@@ -908,6 +908,16 @@ int PanoramiXClearToBackground(ClientPtr client)
     if (result != Success)
 	return result;
 
+    if (win->u.win.root)
+    {
+	xWindowRoot *root = (xWindowRoot *) (ConnectionInfo + connBlockScreenStart);
+
+	if (!stuff->width)
+	    stuff->width = root->pixWidth - stuff->x;
+	if (!stuff->height)
+	    stuff->height = root->pixHeight - stuff->y;
+    }
+
     FOR_NSCREENS_BACKWARD(j) {
 	stuff->window = win->info[j].id;
 	result = (*SavedProcVector[X_ClearArea])(client);

The key idea is that if you pass 0 for width or height to the ClearArea
request, that's supposed to mean "use the width/height of the window".
But like Xinerama's implementation of GetGeometry, if we're asked to
operate on the root window we need to dig the desktop's size out of the
connection setup block instead of using the size from each ScreenRec's
root window.

Does this seem sensible to you?

The only other core request that looks similar is WarpPointer, with its
src-width and src-height parameters. (I didn't even know WarpPointer had
those options...) But XineramaWarpPointer already didn't look at the
window's width or height, it just bypassed the width or height check if
the corresponding parameter was 0, so it's fine. I did find that I'd
missed more code to delete there, though, so that's fixed on my
review-pending branch as well.

Any other review comments, while I go back to watching fireworks cascade
over a Xinerama-spanned pair of xf86-video-nested windows?

Jamey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg-devel/attachments/20110930/91b7d5a0/attachment.pgp>