in Xephyr, using Render to composite a transformed, redirected window has bizarre coordinate problems
@njs
Submitted by Nathaniel J. Smith Assigned to Eric Anholt @anholt
Description
I'm attaching a test program (requires gtk >=2.12, cairo, and python bindings to both). The test program creates two toplevel windows, sets one to manual redirection, and then just repeatedly draws a gradient image into the redirected window, and composites the image of the redirected window into the other 'display' window, using Render (via cairo -- I've verified that the expected Render operations are occurring with xtrace). The display window also has a little white dot placed at where the upper-left corner of the composited image should land, given the transform matrix in use.
To test, run Xephyr, start a window manager, then start the test program and move the two windows around on the screen. Moving the display window has no effect. Moving the redirected window against the root window causes its image inside the display window to veer wildly -- each time the real window goes to the left, its image goes to the right, and so on. The only time it appears at the correct location is if the redirected window is placed at position (0, 0) against the root. (I'll also attach a little ogg video to show this.)
The amount of the offset seems to vary inversely with the scale factor applied. With a scale factor of 1, the display is correct. As the scale factor goes to 1, it looks like the transformed image moves by 1 pixel for every 1 pixel the redirected window moves by. For intermediate scale factors, the transformed image moves by intermediate amounts as the redirected window is moved. See attached screenshot.
I am deeply suspicious of the handling of redirected windows' ->screen_x/->screen_y offsets. It is like one piece of code is expected to leave the offsets in, and then they are corrected for later, but the first piece of code is multiplying them by the scale factor and the latter code is assuming a scale factor of 1 when it applies its correction.... or something.
This is with X.org 1.4.0 (Debian sid, xorg-server 2:1.4-3), on x86-64.
Version: 7.3 (2007.09)