That doesn't really look much of anything like my screen. It looks like it captured one monitor, put it in the middle of another monitor, failed to capture most of the windows, and the windows it did capture are split in two.
Windows 8.1, triple monitor, left is 1080x1920, middle is 1920x1200, right is 1920x1080
smaller version of the screenshot we can inline in the ticket
Do you have the ability to take a more correct screenshot using some other tool so that I can have a better idea of what things are meant to look like?
what it looks like happened, is all the area that the left monitor takes up above the other two got filled with garbage .. the area below the right two got filled with black.. the right hand monitor's image got swapped to the left.. and the open windows got sliced up and moved all over. In the original screenshot, the Opera window with the Xpra wiki in it should have been full screen, but it's showing bits of other windows that were below it, and I think the window that is sliced in two parts there was actually on the right hand monitor instead of the center.
Sounds to me like the screen capture code in GTK has bugs on windows 8 and/or multi monitors setup.
Either way, this should be dealt with before too long as part of #389. Another solution would be the GTK3 port (#90) - assuming that screen capture works better there... which is not a given.
Probably multi-monitors. GTK is really screwey in that respect, especially once you start mixing radically different resolutions.
The successful screenshot that I attached was taken using windows Ctrl-PrintScreen? and then pasted to GIMP. GIMP itself could not grab the whole thing, and would only grab a single display and a tiny piece (about 30 px or so) of the right or the left depending on which monitor the window was on when I hit the Create->From Screenshot button.
I'll be able to deal with this once I get a MS Windows test system setup (works OK in virtualbox)
r10002 probably fixes this, I now have a Windows PC to test on and enough monitors but I am still waiting for the delivery of the HDMI cable I need for testing!
I would like to backport this change because it also drastically improves the performance of the win32 shadow server.
Beta build available for testing: http://xpra.org/beta/windows/
@afarr / @eblade: does this work for you? Bonus points for testing the shadow server:
xpra_cmd shadow :0 --bind-tcp=0.0.0.0:10000
Then connect to this window box as normal on port 10000.
Testing on a windows 8.1 client 0.16.0 r10002 with two displays against a fedora 20 server 0.16.0 r9919 (there weren't pieces of this on the server side, I hope).
Client display set up:
2015-07-22 16:52:43,976 desktop size is 5120x2160 with 1 screen(s): 2015-07-22 16:52:43,976 '1\WinSta-Default' (1354x571 mm - DPI: 96x96) workarea: 5120x2120 2015-07-22 16:52:43,976 DISPLAY1 3840x2160 at 1280x0 (621x341 mm - DPI: 157x160) workarea: 3840x2120 2015-07-22 16:52:43,976 DISPLAY2 1280x720 (597x336 mm - DPI: 54x54) workarea: 1280x680
When I have windows on Display 1, bug report screenshot only captures Display 1. Moving the xpra windows to Display 2, the bug report window opens with no content. All subsequent attempts to create a bug report also produce a blank window - until I disconnect/reconnect.
Upon reconnecting, I am able to use the bug report tool to take another screen shot, but it again takes only a shot of Display 1 and again brings up an empty window if I try to open the bug report tool a second time, despite having thought to move the xpra windows to Display 2.
I'll attach xpra info (used your windows client but our fedora server build) and a screenshot of the little greyed out bug report window.
screenshot of blank bug report window
xpra info with blank bug report tool window
Blank bug report window next to an xpra firefox window.
So, I got an HDMI cable in the end and it turns out that the Pillow screen capture is also buggy: Python PIL library— Is there a way to select which screen ImageGrab.grab() grabs in a multi-monitor setup?
So r10026 implements screen capture using native pywin32 calls instead (+fixup in r10053). This is suitable for backporting. The shadow_server.py can be used for testing the screen capture quickly and it will save a file named "screenshot.png" in the current working directory.
With r10027 onwards, the bug report tool can also be accessed from the launcher. As for the blank bug report window, this has nothing to do with multiple monitors or win32, it just shows up as blank whenever you open it for the second time around from the same process. This is fixed in r10029. (will also backport)
@afarr / @eblade: can you still break it somehow? (new beta uploaded)
Well, aside from trying to declare that copying the entire contents of the bug report generated to clipboard failing to allow the pasting of a screen shot into a .rtf file, I couldn't seem to break it.
Screenshot with multi-dispaly desktop captured both displays, with black space to indicate the portion of the smaller window which had no content (while putting the whole "desktop" into a box).
Bug tool window appeared as expected and functioned as expected three times in a row. Not too shabby. Can probably close, unless eblade can come up with a way to break it.
Looks fine to me. Closing. I will re-test once my new cables are delivered (so I can test with multiple displays)
screenshot from win10 confirming fix
Looks good from here now. Attached verification (screenshot.png) that it's working from Win10.
oh, the left monitor seems to extend slightly below the area where the taskbar is. nothing major, though.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/637