Xpra: Ticket #976: scale the local display

Allow the client to "lie" about its real display dimensions (and maybe still report the actual correct values somewhere) so that the server can render things at a different resolution and save CPU, memory and bandwidth.

This will allow us to handle 4k screens a lot better: we can render at 2k or even just 1080p and upscale client side. For a lot of content, especially video-like pixels, it is a lot more efficient than upscaling the video (in the client application: browser or video player) then downscaling it before compressing it, only to upscale it at the other end. The compression can introduce a lot of blurring which gets magnified. Compressing 4k is just too expensive in most cases, even with hardware assisted encoding. With a smaller virtual screen size, we are more likely to be able to compress losslessly or at a better quality and higher framerate. The client-side upscaling may also be able to do the anti-aliasing for us. This is what MS Windows does already for applications which are not DPI aware.

Maybe worth doing if dummy + randr does not get fixed in time: when we are scaling things, we could also use the full virtual screen's size (which may be bigger than the size the client requested) and let the client scale it appropriately. That's as long as the differences are minimal (say 10%?). It will avoid bugs with applications which use the display size without checking the desktop / workarea / available size options.

Related / impacted tickets:



Fri, 04 Sep 2015 17:27:34 GMT - Antoine Martin: attachment set

work in progress - rendering part not done (big)


Fri, 04 Sep 2015 17:28:22 GMT - Antoine Martin: status changed

From the patch above, things that need to be fixed or added:

to verify:


Sat, 05 Sep 2015 07:56:34 GMT - Antoine Martin: attachment set

mostly working patch - opengl done


Mon, 07 Sep 2015 05:38:32 GMT - Antoine Martin: attachment set

working with all backends: cairo, pixmap and opengl!


Mon, 07 Sep 2015 06:17:25 GMT - Antoine Martin:

Mostly done in r10533, currently only accessible via env vars. It looks really good and uses a lot less bandwidth! (much better than the automatic scaling - which may still kick in, but much less)

Note: the pixmap and cairo backings look quite ugly compared to the opengl one because we only repaint the area that has changed whereas the opengl backend repaints everything (because this is cheap) and therefore avoids aliasing issues on the edge of the area being repainted. We could update those backends I guess. Needs testing to decide if it is worth it. The Pixmap backend upscales the picture using the "HYPER" gdk filter, this can be overriden with XPRA_SCALING_INTERPOLATION=FILTERNAME - see here for the list of options: pixbuf.scale.

Still TODO:


Tue, 08 Sep 2015 14:30:25 GMT - Antoine Martin:

Important fixup in r10553 - unscaled opengl rendering was broken since r10533 on platforms without double-buffering (all but win32).


Fri, 11 Sep 2015 18:30:03 GMT - Antoine Martin:

Here are some usage examples:

Still TODO:

(some of these items are likely to be scheduled for a future release, ie: xshape)


Wed, 16 Sep 2015 09:08:32 GMT - Antoine Martin: owner, status changed


@afarr: ready for testing:


future stuff (recording here for lack of a better place):


Fri, 18 Sep 2015 21:28:01 GMT - J. Max Mena:

Running a Fedora 20 r10666 client against a Fedora 21 r10666 Server:


Sat, 19 Sep 2015 04:48:28 GMT - Antoine Martin: owner changed

System tray forwarding does not work properly


Which desktop environment do you use? With gnome3 and topicons, the tray icons don't work half the time - that's even without xpra...

And even without the topicons extension, the horrible and annoying little widget at the bottom left hand side of the screen doesn't work either!

I'll take a look later since I also get problems with win32 (and that one works reliably since Windows 2000!)

Some minor fixes in this area in r10667. (should help when upscaling)


Cursor scales down, but stays small when resetting scale (shift + alt + * (even sticks after a reconnect) Edit: The cursor does not scale up properly as well


Fixes to upscaling cursors in r10668.

Notes:


Not sure how to test xshape


xeyes


Thu, 08 Oct 2015 14:47:57 GMT - Antoine Martin: priority changed

raising the priority: this is one of the most important new features in 0.16, and I would like to make "auto" mode the default


Thu, 08 Oct 2015 21:44:11 GMT - J. Max Mena:

The client(fedora 20) is currently running Mate, but I have Gnome, and Xfce installed - and use them from time to time.

Upped server (Fedora 21) and client (fedora 20) to trunk r10765:

-d cursor output(connected, scaled a couple times, disconnected):

2015-10-08 14:33:13,534 Attached to tcp:10.0.32.139:2200 (press Control-C to detach)
2015-10-08 14:33:13,891 window dimensions are wrong: 1x1
2015-10-08 14:33:13,926 set_windows_cursor([ClientWindow(1), ClientWindow(40), ClientWindow(10), ClientWindow(11), ClientWindow(12), ClientWindow(18)], ..)
/usr/lib64/python2.7/site-packages/gobject/constants.py:24: Warning: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed
  import gobject._gobject
2015-10-08 14:33:15,622 set_windows_cursor([ClientWindow(1), ClientWindow(40), ClientWindow(10), ClientWindow(11), ClientWindow(12), ClientWindow(18)], ..)
2015-10-08 14:33:15,623 setting new cursor by name: left_ptr=<enum GDK_LEFT_PTR of type GdkCursorType>
2015-10-08 14:33:15,624 make_cursor(..)=<gtk.gdk.Cursor at 0x3cf9d00: GDK_LEFT_PTR>
2015-10-08 14:33:15,664 set_windows_cursor([ClientWindow(1), ClientWindow(40), ClientWindow(10), ClientWindow(11), ClientWindow(12), ClientWindow(18)], ..)
2015-10-08 14:33:15,665 setting new cursor by name: left_ptr=<enum GDK_LEFT_PTR of type GdkCursorType>
2015-10-08 14:33:15,665 make_cursor(..)=<gtk.gdk.Cursor at 0x3cf9b48: GDK_LEFT_PTR>
2015-10-08 14:33:15,875 set_windows_cursor([ClientWindow(1), ClientWindow(40), ClientWindow(10), ClientWindow(11), ClientWindow(12), ClientWindow(18)], ..)
2015-10-08 14:33:15,876 setting new cursor by name: hand2=<enum GDK_HAND2 of type GdkCursorType>
2015-10-08 14:33:15,877 make_cursor(..)=<gtk.gdk.Cursor at 0x3cf9b48: GDK_HAND2>
2015-10-08 14:33:15,979 set_windows_cursor([ClientWindow(1), ClientWindow(40), ClientWindow(10), ClientWindow(11), ClientWindow(12), ClientWindow(18)], ..)
2015-10-08 14:33:15,980 setting new cursor by name: left_ptr=<enum GDK_LEFT_PTR of type GdkCursorType>
2015-10-08 14:33:15,981 make_cursor(..)=<gtk.gdk.Cursor at 0x3cf9d00: GDK_LEFT_PTR>
2015-10-08 14:33:16,775 sound-sink using audio codec: MPEG 1 Audio, Layer 3 (MP3)
2015-10-08 14:33:18,032 sending updated screen size to server: 3840x2160 with 1 screens
2015-10-08 14:33:18,033   :0.0 (602x343 mm - DPI: 162x159) workarea: 3840x2064 at 0x48
2015-10-08 14:33:18,035     DVI-I-1 (600x340 mm - DPI: 162x161)
2015-10-08 14:33:18,394 scaling_changed() resetting cursors for: [ClientWindow(18)]
2015-10-08 14:33:18,395 set_windows_cursor([ClientWindow(18)], ..)
2015-10-08 14:33:18,396 setting new cursor by name: left_ptr=<enum GDK_LEFT_PTR of type GdkCursorType>
2015-10-08 14:33:18,397 make_cursor(..)=<gtk.gdk.Cursor at 0x3efc238: GDK_LEFT_PTR>
2015-10-08 14:33:19,387 set_windows_cursor([ClientWindow(1), ClientWindow(40), ClientWindow(10), ClientWindow(11), ClientWindow(12), ClientWindow(18)], ..)
2015-10-08 14:33:19,435 set_windows_cursor([ClientWindow(1), ClientWindow(40), ClientWindow(10), ClientWindow(11), ClientWindow(12), ClientWindow(18)], ..)
2015-10-08 14:33:19,438 setting new cursor by name: xterm=<enum GDK_XTERM of type GdkCursorType>
2015-10-08 14:33:19,439 make_cursor(..)=<gtk.gdk.Cursor at 0x3cf9df0: GDK_XTERM>
2015-10-08 14:33:20,346 set_windows_cursor([ClientWindow(1), ClientWindow(40), ClientWindow(10), ClientWindow(11), ClientWindow(12), ClientWindow(18)], ..)
2015-10-08 14:33:20,347 setting new cursor by name: left_ptr=<enum GDK_LEFT_PTR of type GdkCursorType>
2015-10-08 14:33:20,348 make_cursor(..)=<gtk.gdk.Cursor at 0x3cf9d28: GDK_LEFT_PTR>
2015-10-08 14:33:20,564 set_windows_cursor([ClientWindow(1), ClientWindow(40), ClientWindow(10), ClientWindow(11), ClientWindow(12), ClientWindow(18)], ..)
2015-10-08 14:33:20,565 setting new cursor by name: hand2=<enum GDK_HAND2 of type GdkCursorType>
2015-10-08 14:33:20,566 make_cursor(..)=<gtk.gdk.Cursor at 0x3cf9d28: GDK_HAND2>
2015-10-08 14:33:20,603 set_windows_cursor([ClientWindow(1), ClientWindow(40), ClientWindow(10), ClientWindow(11), ClientWindow(12), ClientWindow(18)], ..)
2015-10-08 14:33:20,605 setting new cursor by name: left_ptr=<enum GDK_LEFT_PTR of type GdkCursorType>
2015-10-08 14:33:20,606 make_cursor(..)=<gtk.gdk.Cursor at 0x3cf9cd8: GDK_LEFT_PTR>
2015-10-08 14:33:21,613 set_windows_cursor([ClientWindow(1), ClientWindow(40), ClientWindow(10), ClientWindow(11), ClientWindow(12), ClientWindow(18)], ..)
2015-10-08 14:33:21,614 setting new cursor by name: left_ptr=<enum GDK_LEFT_PTR of type GdkCursorType>
2015-10-08 14:33:21,615 make_cursor(..)=<gtk.gdk.Cursor at 0x3cf9df0: GDK_LEFT_PTR>

Fri, 09 Oct 2015 10:35:08 GMT - Antoine Martin:

Ah, right, sorry about that, for testing I had been running my client with:

XPRA_USE_LOCAL_CURSORS=0 xpra ...

Which disabled named cursors, r10781 ensures we never use named cursors when scaling (as named cursors cannot be resized).

I'm still seeing cursors that seem too big when scaling or when using XPRA_USE_LOCAL_CURSORS=0, but I think that's just a different server configuration. If everything else works, please re-assign to me and I'll take another look.


Fri, 09 Oct 2015 19:57:15 GMT - J. Max Mena: owner changed

Upped to r10783:


Here's the -d cursor output for a quick connect-and-scale session: attachment/ticket/976/976-comment11-cursor-log.txt


Sat, 10 Oct 2015 05:44:17 GMT - Antoine Martin: attachment set

moving the cursor log to an attachment


Sat, 10 Oct 2015 06:08:10 GMT - Antoine Martin: status changed

Windows client does not scale properly (not sure if it's expected or not)


It is.

The situation on win32 is unclear, see #998. Cursors are meant to be using a fixed size so for the time being we do this:


Scaling down then attempting to use VLC's tray icon in Windows causes the right click to be sent to Google-Chrome (?)...


That's because we're not adjusting the tray icon's location properly to its new server-side on-virtual-screen position (scaled). And so the clicks end up landing somewhere else... Will fix.


Sun, 11 Oct 2015 16:48:43 GMT - Antoine Martin: owner, status changed

As of r10798 we now paint the monitors and the workarea bounds onto the virtual screen with sync-xvfb (see #988), and the tray seems to be in the right place.

Turns out that this HUGE bug was not tray related but only more apparent with the systray, and it would have caused us all sorts of problems elsewhere - now fixed in r10802. Works for me with win32 and vlc.

PS: I'm seeing some visual corruption with win32 when dowscaling without opengl. (will try to deal with it later - should be good enough for testing as it is)


Tue, 13 Oct 2015 19:06:33 GMT - J. Max Mena: owner changed

Upped to r10786 Server and r10810 Client (Installed from xpra.org/beta):


Since everything's working, I'll pass this back to you to decide what else needs to be done.


Wed, 14 Oct 2015 04:45:48 GMT - Antoine Martin: owner changed

taskbar icon when scaling up and down... mild corruption only notable in Windows


Yes, I had noticed that - it looks as if it's painting the new one on top without clearing the previous one, but I have no idea where that is coming from - so we will have to live with it for now.

We already have a test app we can use to verify that changing the tray icon works and it's running fine with Windows clients: browser/xpra/trunk/src/tests/xpra/test_apps/test_system_tray.py (just click on the tray icon to change to the next one)


Since this works well enough, I have made "auto" mode the default in r10831. This is a big change.

@afarr / maxmylyn: this will need testing with 4k monitors (and multiple monitors, etc), especially with different DPI settings (see #163 / Writing DPI-Aware Desktop and Win32 Applications).

Windows 8.1 onwards used to scale our windows automatically on high dpi displays (see SetProcessDpiAwareness. You can use XPRA_DPI_AWARENESS=VALUE to change this value (Process_System_DPI_Aware = 1, Process_DPI_Unaware = 0, Process_Per_Monitor_DPI_Aware = 2 - I don't think we will be able to handle per monitor DPI awareness for a while without some major changes X11 side). Use -d screen to see the DPI calls, which should happen very early in the client startup process.

Note: I have no way to test this as I don't have a non-virtualized Windows 8.1 or later system to test on.

Important: without the "auto" desktop scaling mode added in r10831, we may end up using a lot more bandwidth with r10832 on Windows 8.1 and later since we should then be using "actual" monitor resolution instead of the DPI downscaled one. (a lot more pixels to forward) Why do we want to do this ourselves? We can scale more than the OS and we will get better quality if things are scaled only once by our client.

Maybe we should be taking into account the desired DPI to decide when to scale instead of just the display resolution? (if the user or OS chooses a high DPI, then we may want to scale - using Determining the DPI Scale Factor)

Maybe also re-test #919 at the same time as we may have to catch WM_DPICHANGED events (this page has a nice summary table listing scaling values for each DPI range) and check to see if the values for the frame extents have changed.

Note: I don't think we should be using the same scaling values as what MS Windows uses: scaling more is good for us as we save more CPU, bandwidth and we get a better framerate and user density.


Fri, 16 Oct 2015 19:46:50 GMT - alas:

Testing with windows client 0.16.0 r10853 against 0.16.0 r10853 fedora 21 server.

Just for a baseline, initial connection client output of desktop size and dpi:

2015-10-16 11:02:19,516  desktop size is 5120x2160 with 1 screen(s):
2015-10-16 11:02:19,516   Default (1354x571 mm - DPI: 96x96) workarea: 5120x2120
2015-10-16 11:02:19,516     DISPLAY1 3840x2160 at 1280x0 (621x341 mm - DPI: 157x160) workarea: 5120x2120
2015-10-16 11:02:19,516     DISPLAY2 1280x720 (597x336 mm - DPI: 54x54) workarea: 5120x2120
2015-10-16 11:02:19,516  scaled using 2 x 2 to:
2015-10-16 11:02:19,516   Default (1354x571 mm - DPI: 48x48) workarea: 2560x1060
2015-10-16 11:02:19,516     DISPLAY1 1920x1080 at 640x0 (621x341 mm - DPI: 78x80) workarea: 2560x1060
2015-10-16 11:02:19,516     DISPLAY2 640x360 (597x336 mm - DPI: 27x27) workarea: 2560x1060
2015-10-16 11:02:19,657 server: Linux Fedora 21 Twenty One, Xpra version 0.16.0-r10854

Looks like attempts at scaling down below 1x1 on this size desktop (beyond the bounds of sanity really) is nicely caught, with a client warning, and refuses to scale down any further:

2015-10-16 11:03:49,463 Warning: cannot scale by 0.5 x 0.5
2015-10-16 11:03:49,463  the scaled client screen 5120 x 2160 -> 10240 x 4320
2015-10-16 11:03:49,463  would overflow the server's screen: 8192 x 4096
2015-10-16 11:03:49,463  using 0.625 x 0.625
2015-10-16 11:03:49,463 sending updated screen size to server: 8192x3456 with 1 screens
2015-10-16 11:03:49,463   Default (1354x571 mm - DPI: 153x153) workarea: 8192x3392
2015-10-16 11:03:49,463     DISPLAY1 6144x3456 at 2048x0 (621x341 mm - DPI: 251x257) workarea: 8192x3392
2015-10-16 11:03:49,463     DISPLAY2 2048x1152 (597x336 mm - DPI: 87x87) workarea: 8192x3392

Scaling up, however, doesn't seem to have a sanity check - using the shortcut shift-alt-+ 4 times from the .625x.625 lower scaling limit triggers a crash client side.

Successive client side display output (with the client side IHDR & IDAT values peeled out, let me know if including them would be of use):

2015-10-16 11:04:05,786 sending updated screen size to server: 4096x1728 with 1 screens
2015-10-16 11:04:05,786   Default (1354x571 mm - DPI: 76x76) workarea: 4096x1696
2015-10-16 11:04:05,786     DISPLAY1 3072x1728 at 1024x0 (621x341 mm - DPI: 125x128) workarea: 4096x1696
2015-10-16 11:04:05,786     DISPLAY2 1024x576 (597x336 mm - DPI: 43x43) workarea: 4096x1696
...
2015-10-16 11:04:06,812 sending updated screen size to server: 2048x864 with 1 screens
2015-10-16 11:04:06,812   Default (1354x571 mm - DPI: 38x38) workarea: 2048x848
2015-10-16 11:04:06,812     DISPLAY1 1536x864 at 512x0 (621x341 mm - DPI: 62x64) workarea: 2048x848
2015-10-16 11:04:06,812     DISPLAY2 512x288 (597x336 mm - DPI: 21x21) workarea: 2048x848
...
2015-10-16 11:04:09,279 sending updated screen size to server: 1024x432 with 1 screens
2015-10-16 11:04:09,279   Default (1354x571 mm - DPI: 19x19) workarea: 1024x424
2015-10-16 11:04:09,279     DISPLAY1 768x432 at 256x0 (621x341 mm - DPI: 31x32) workarea: 1024x424
2015-10-16 11:04:09,296     DISPLAY2 256x144 (597x336 mm - DPI: 10x10) workarea: 1024x424
...
2015-10-16 11:04:25,822 sending updated screen size to server: 512x216 with 1 screens
2015-10-16 11:04:25,823   Default (1354x571 mm - DPI: 9x9) workarea: 512x212
2015-10-16 11:04:25,823     DISPLAY1 384x216 at 128x0 (621x341 mm - DPI: 15x16) workarea: 512x212
2015-10-16 11:04:25,825     DISPLAY2 128x72 (597x336 mm - DPI: 5x5) workarea: 512x212
pnc=: N2015-10-16 11:04:35,078 sound-sink stopping
C:\Program Files (x86)\Xpra>

The only output I get server side is:

2015-10-16 11:04:24,784 DPI set to 96 x 97 (wanted 96 x 96)
2015-10-16 11:04:24,786 sent updated screen size to 1 client: 512x384 (max 8192x4096)
2015-10-16 11:04:34,050 internal error: read connection tcp socket: 10.0.32.136:2200 <- 10.0.11.162:49634 reset
2015-10-16 11:04:34,051  [Errno 104] Connection reset by peer

Reconnecting the client with -d screen I get this client side on re-connection to the same server session:

C:\Program Files (x86)\Xpra>xpra_cmd.exe attach tcp:10.0.32.136:2200 --sharing --password-file=key.txt --encryption-keyfile=key.txt --encryption=AES -d screen
2015-10-16 12:06:31,049 SetProcessDPIAware()=1
2015-10-16 12:06:31,049 SetProcessDPIAwareness(1) failed: function 'SetProcessDPIAwareness' not found
2015-10-16 12:06:31,049  (not available on MS Windows before version 8
2015-10-16 12:06:31,135 xpra gtk2 client version 0.16.0-r10853
2015-10-16 12:06:31,960 OpenGL_accelerate module loaded
2015-10-16 12:06:32,055 receiving data using AES encryption
2015-10-16 12:06:32,210 sending data using AES encryption
2015-10-16 12:06:32,305  detected keyboard: layout=us
2015-10-16 12:06:32,305 get_screen_sizes(1.000000, 1.000000) found 1 screens
2015-10-16 12:06:32,305  screen 0 has 2 monitors
2015-10-16 12:06:32,305 get_workareas() GetMonitorInfo(<PyHANDLE:65537>)={'Device': '\\\\.\\DISPLAY1', 'Work': (0, 0, 3840, 2120), 'Flags': 1, 'Monitor': (0, 0, 3840
, 2160)}
2015-10-16 12:06:32,305 get_workareas() GetMonitorInfo(<PyHANDLE:65539>)={'Device': '\\\\.\\DISPLAY2', 'Work': (-1280, 0, 0, 680), 'Flags': 0, 'Monitor': (-1280, 0,
0, 720)}
2015-10-16 12:06:32,305 get_workareas()=[(0, 0, 3840, 2120), (0, 0, 1280, 680)]
2015-10-16 12:06:32,305  monitor 0: ['\\\\.\\DISPLAY1', 1280, 0, 3840, 2160, 621, 341]
2015-10-16 12:06:32,305  monitor 1: ['\\\\.\\DISPLAY2', 0, 0, 1280, 720, 597, 336]
2015-10-16 12:06:32,305 get_workarea() absolute total monitor dimensions: (3840, 2160)
2015-10-16 12:06:32,305  workarea=(0, 0, 5120, 2120)
2015-10-16 12:06:32,305  screen 0: ('1\\WinSta0\\Default', 5120, 2160, 1354, 571, [('\\\\.\\DISPLAY1', 1280, 0, 3840, 2160, 621, 341, 0, 0, 3840, 2120), ('\\\\.\\DIS
PLAY2', 0, 0, 1280, 720, 597, 336, 0, 0, 1280, 680)], 0, 0, 5120, 2120)
2015-10-16 12:06:32,305  desktop size is 5120x2160 with 1 screen(s):
2015-10-16 12:06:32,305   Default (1354x571 mm - DPI: 96x96) workarea: 5120x2120
2015-10-16 12:06:32,305     DISPLAY1 3840x2160 at 1280x0 (621x341 mm - DPI: 157x160) workarea: 5120x2120
2015-10-16 12:06:32,305     DISPLAY2 1280x720 (597x336 mm - DPI: 54x54) workarea: 5120x2120
2015-10-16 12:06:32,305  scaled using 2 x 2 to:
2015-10-16 12:06:32,305 get_screen_sizes(2.000000, 2.000000) found 1 screens
2015-10-16 12:06:32,305  screen 0 has 2 monitors
2015-10-16 12:06:32,305 get_workareas() GetMonitorInfo(<PyHANDLE:65537>)={'Device': '\\\\.\\DISPLAY1', 'Work': (0, 0, 3840, 2120), 'Flags': 1, 'Monitor': (0, 0, 3840
, 2160)}
2015-10-16 12:06:32,305 get_workareas() GetMonitorInfo(<PyHANDLE:65539>)={'Device': '\\\\.\\DISPLAY2', 'Work': (-1280, 0, 0, 680), 'Flags': 0, 'Monitor': (-1280, 0,
0, 720)}
2015-10-16 12:06:32,305 get_workareas()=[(0, 0, 3840, 2120), (0, 0, 1280, 680)]
2015-10-16 12:06:32,305  monitor 0: ['\\\\.\\DISPLAY1', 640, 0, 1920, 1080, 621, 341]
2015-10-16 12:06:32,305  monitor 1: ['\\\\.\\DISPLAY2', 0, 0, 640, 360, 597, 336]
2015-10-16 12:06:32,319 get_workarea() absolute total monitor dimensions: (3840, 2160)
2015-10-16 12:06:32,319  workarea=(0, 0, 5120, 2120)
2015-10-16 12:06:32,319  screen 0: ('1\\WinSta0\\Default', 2560, 1080, 1354, 571, [('\\\\.\\DISPLAY1', 640, 0, 1920, 1080, 621, 341, 0, 0, 1920, 1060), ('\\\\.\\DISP
LAY2', 0, 0, 640, 360, 597, 336, 0, 0, 640, 340)], 0, 0, 2560, 1060)
2015-10-16 12:06:32,319   Default (1354x571 mm - DPI: 48x48) workarea: 2560x1060
2015-10-16 12:06:32,319     DISPLAY1 1920x1080 at 640x0 (621x341 mm - DPI: 78x80) workarea: 2560x1060
2015-10-16 12:06:32,319     DISPLAY2 640x360 (597x336 mm - DPI: 27x27) workarea: 2560x1060
2015-10-16 12:06:32,319 get_vrefresh()=29
2015-10-16 12:06:32,476 server: Linux Fedora 21 Twenty One, Xpra version 0.16.0-r10854
2015-10-16 12:06:32,555 Attached to tcp:10.0.32.136:2200 (press Control-C to detach)

And I get this repeatedly as I doggedly alt-shift-+ past a 6x6 dpi:

2015-10-16 12:37:57,841 do_paint_rgb32 error
Traceback (most recent call last):
  File "xpra\client\window_backing_base.pyc", line 309, in do_paint_rgb32
  File "xpra\client\gl\gl_window_backing_base.pyc", line 625, in _do_paint_rgb32
  File "xpra\client\gl\gl_window_backing_base.pyc", line 641, in _do_paint_rgb
  File "xpra\client\gl\gl_window_backing_base.pyc", line 366, in gl_init
  File "errorchecker.pyx", line 53, in OpenGL_accelerate.errorchecker._ErrorChecker.glCheckError (c:\Users\mcfletch\OpenGL-dev\OpenGL-ctypes\OpenGL_accelerate\src\er
rorchecker.c:1218)
GLError: GLError(
        err = 1285,
        description = 'out of memory',
        baseOperation = glViewport,
        cArguments = (0, 0, 487, 290)
)
2015-10-16 12:37:57,904 do_paint_rgb32 error
Traceback (most recent call last):
  File "xpra\client\window_backing_base.pyc", line 309, in do_paint_rgb32
  File "xpra\client\gl\gl_window_backing_base.pyc", line 625, in _do_paint_rgb32
  File "xpra\client\gl\gl_window_backing_base.pyc", line 641, in _do_paint_rgb
  File "xpra\client\gl\gl_window_backing_base.pyc", line 366, in gl_init
  File "errorchecker.pyx", line 53, in OpenGL_accelerate.errorchecker._ErrorChecker.glCheckError (c:\Users\mcfletch\OpenGL-dev\OpenGL-ctypes\OpenGL_accelerate\src\er
rorchecker.c:1218)
GLError: GLError(
        err = 1285,
        description = 'out of memory',
        baseOperation = glViewport,
        cArguments = (0, 0, 487, 290)
)
**
GLib:ERROR:gmain.c:2444:g_main_dispatch: assertion failed: (current->dispatching_sources == &current_source_link)
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
2015-10-16 12:38:11,844 sound-sink stopping

Server-side, this time around, I'm seeing this:

2015-10-16 12:37:56,675 client_decode_error: do_paint_rgb32 error: GLError(
        err = 1285,
        description = 'out of memory',
        baseOperation = glViewport,
        cArguments = (0, 0, 487, 290)
) (-1)
2015-10-16 12:37:56,736 client_decode_error: do_paint_rgb32 error: GLError(
        err = 1285,
        description = 'out of memory',
        baseOperation = glViewport,
        cArguments = (0, 0, 487, 290)
) (-1)
2015-10-16 12:38:10,730 internal error: read connection tcp socket: 10.0.32.136:2200 <- 10.0.11.162:50088 reset
2015-10-16 12:38:10,731  [Errno 104] Connection reset by peer

... but the server is still apparently running.

I'll attach an xpra info from the server after the client's initial and second crash both.


Fri, 16 Oct 2015 19:52:21 GMT - alas: attachment set

initial scaling induced crash server info - comment 16


Fri, 16 Oct 2015 19:53:08 GMT - alas: attachment set

scaling up, up, and away - crashes client ... comment16


Fri, 16 Oct 2015 21:57:59 GMT - alas:

Testing against 0.16.0 r10854 fedora 21 server with 0.16.0 r10854 osx client...

Re-trying the last of the above with -d keyboard, it looks like the +/= key of the OSX laptop keyboard is being read as 'plusminus' by the server keymapping:

2015-10-16 14:47:36,503 parse_key_event(<gtk.gdk.Event at 0x9242950: GDK_KEY_PRESS keyval=Alt_L>, True)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 1, 'string': '', 'keyname': 'Alt_L', 'pressed': True, 'keyval': 65513, 'keycode': 58}>
2015-10-16 14:47:36,503 handle_key_action(GLClientWindow(10 : gtk2.GLWindowBacking(10, (576, 501), YUV420P)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 1, 'string': '', 'keyname': 'Alt_L', 'pressed': True, 'keyval': 65513, 'keycode': 58}>) wid=10
2015-10-16 14:47:36,503 send_key_action(10, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 1, 'string': '', 'keyname': 'Alt_L', 'pressed': True, 'keyval': 65513, 'keycode': 58}>)
2015-10-16 14:47:37,182 mask_to_names names=['mod1'], meta_on=False, meta_set=True, control_set=False
2015-10-16 14:47:37,183 mask_to_names(<flags GDK_MOD1_MASK of type GdkModifierType>)=['mod1', 'mod2']
2015-10-16 14:47:37,183 parse_key_event(<gtk.gdk.Event at 0x9242950: GDK_KEY_PRESS keyval=Shift_L>, True)=<GTKKeyEvent object, contents: {'modifiers': ['mod1', 'mod2'], 'group': 1, 'string': '', 'keyname': 'Shift_L', 'pressed': True, 'keyval': 65505, 'keycode': 56}>
2015-10-16 14:47:37,183 handle_key_action(GLClientWindow(10 : gtk2.GLWindowBacking(10, (576, 501), YUV420P)), <GTKKeyEvent object, contents: {'modifiers': ['mod1', 'mod2'], 'group': 1, 'string': '', 'keyname': 'Shift_L', 'pressed': True, 'keyval': 65505, 'keycode': 56}>) wid=10
2015-10-16 14:47:37,183 send_key_action(10, <GTKKeyEvent object, contents: {'modifiers': ['mod1', 'mod2'], 'group': 1, 'string': '', 'keyname': 'Shift_L', 'pressed': True, 'keyval': 65505, 'keycode': 56}>)
2015-10-16 14:47:37,725 mask_to_names names=['mod1', 'shift'], meta_on=False, meta_set=True, control_set=False
2015-10-16 14:47:37,726 mask_to_names(<flags GDK_SHIFT_MASK | GDK_MOD1_MASK of type GdkModifierType>)=['mod1', 'shift', 'mod2']
2015-10-16 14:47:37,726 parse_key_event(<gtk.gdk.Event at 0x92428d8: GDK_KEY_PRESS keyval=plusminus>, True)=<GTKKeyEvent object, contents: {'modifiers': ['mod1', 'shift', 'mod2'], 'group': 1, 'string': '\xc2\xb1', 'keyname': 'plusminus', 'pressed': True, 'keyval': 177, 'keycode': 24}>
2015-10-16 14:47:37,726 handle_key_action(GLClientWindow(10 : gtk2.GLWindowBacking(10, (576, 501), YUV420P)), <GTKKeyEvent object, contents: {'modifiers': ['mod1', 'shift', 'mod2'], 'group': 1, 'string': '\xc2\xb1', 'keyname': 'plusminus', 'pressed': True, 'keyval': 177, 'keycode': 24}>) wid=10
2015-10-16 14:47:37,726 send_key_action(10, <GTKKeyEvent object, contents: {'modifiers': ['mod1', 'shift', 'mod2'], 'group': 1, 'string': '\xc2\xb1', 'keyname': 'plusminus', 'pressed': True, 'keyval': 177, 'keycode': 24}>)
2015-10-16 14:47:37,983 mask_to_names names=['mod1', 'shift'], meta_on=False, meta_set=True, control_set=False
2015-10-16 14:47:37,983 mask_to_names(<flags GDK_SHIFT_MASK | GDK_MOD1_MASK of type GdkModifierType>)=['mod1', 'shift', 'mod2']
2015-10-16 14:47:37,983 parse_key_event(<gtk.gdk.Event at 0x92428d8: GDK_KEY_RELEASE keyval=plusminus>, False)=<GTKKeyEvent object, contents: {'modifiers': ['mod1', 'shift', 'mod2'], 'group': 1, 'string': '\xc2\xb1', 'keyname': 'plusminus', 'pressed': False, 'keyval': 177, 'keycode': 24}>
2015-10-16 14:47:37,983 handle_key_action(GLClientWindow(10 : gtk2.GLWindowBacking(10, (576, 501), YUV420P)), <GTKKeyEvent object, contents: {'modifiers': ['mod1', 'shift', 'mod2'], 'group': 1, 'string': '\xc2\xb1', 'keyname': 'plusminus', 'pressed': False, 'keyval': 177, 'keycode': 24}>) wid=10
2015-10-16 14:47:37,983 send_key_action(10, <GTKKeyEvent object, contents: {'modifiers': ['mod1', 'shift', 'mod2'], 'group': 1, 'string': '\xc2\xb1', 'keyname': 'plusminus', 'pressed': False, 'keyval': 177, 'keycode': 24}>)
2015-10-16 14:47:38,150 mask_to_names names=['mod1', 'shift'], meta_on=False, meta_set=True, control_set=False
2015-10-16 14:47:38,151 mask_to_names(<flags GDK_SHIFT_MASK | GDK_MOD1_MASK of type GdkModifierType>)=['mod1', 'shift', 'mod2']
2015-10-16 14:47:38,151 parse_key_event(<gtk.gdk.Event at 0x92428d8: GDK_KEY_RELEASE keyval=Shift_L>, False)=<GTKKeyEvent object, contents: {'modifiers': ['mod1', 'shift', 'mod2'], 'group': 1, 'string': '', 'keyname': 'Shift_L', 'pressed': False, 'keyval': 65505, 'keycode': 56}>
2015-10-16 14:47:38,151 handle_key_action(GLClientWindow(10 : gtk2.GLWindowBacking(10, (576, 501), YUV420P)), <GTKKeyEvent object, contents: {'modifiers': ['mod1', 'shift', 'mod2'], 'group': 1, 'string': '', 'keyname': 'Shift_L', 'pressed': False, 'keyval': 65505, 'keycode': 56}>) wid=10
2015-10-16 14:47:38,151 send_key_action(10, <GTKKeyEvent object, contents: {'modifiers': ['mod1', 'shift', 'mod2'], 'group': 1, 'string': '', 'keyname': 'Shift_L', 'pressed': False, 'keyval': 65505, 'keycode': 56}>)
2015-10-16 14:47:38,174 mask_to_names names=['mod1'], meta_on=False, meta_set=True, control_set=False
2015-10-16 14:47:38,175 mask_to_names(<flags GDK_MOD1_MASK of type GdkModifierType>)=['mod1', 'mod2']
2015-10-16 14:47:38,175 parse_key_event(<gtk.gdk.Event at 0x92428c0: GDK_KEY_RELEASE keyval=Alt_L>, False)=<GTKKeyEvent object, contents: {'modifiers': ['mod1', 'mod2'], 'group': 0, 'string': '', 'keyname': 'Alt_L', 'pressed': False, 'keyval': 65513, 'keycode': 58}>
2015-10-16 14:47:38,175 handle_key_action(GLClientWindow(10 : gtk2.GLWindowBacking(10, (576, 501), YUV420P)), <GTKKeyEvent object, contents: {'modifiers': ['mod1', 'mod2'], 'group': 0, 'string': '', 'keyname': 'Alt_L', 'pressed': False, 'keyval': 65513, 'keycode': 58}>) wid=10
2015-10-16 14:47:38,175 send_key_action(10, <GTKKeyEvent object, contents: {'modifiers': ['mod1', 'mod2'], 'group': 0, 'string': '', 'keyname': 'Alt_L', 'pressed': False, 'keyval': 65513, 'keycode': 58}>)

With all the above said, I'll assume the odd behavior on this osx system when trying to manipulate the scaling (with a chromium browser the contents of the tabs seems to zoom in and out, while the address bar and tab bar remain at whatever the default scaling is).

Perhaps a link through the tray/application menu for users with annoying keyboard layouts would be worth the effort? Maybe a control channel switch?


Sat, 17 Oct 2015 07:19:19 GMT - Antoine Martin:

Scaling up, however, doesn't seem to have a sanity check


None should be needed.

Since we get an "out of memory" in opengl, it would be very useful to know which opengl driver you used for testing, so r10890 will show that by default in the client output from now on. (not as good as the gl_check / GL info exe output, but better than nothing).

I will take a stab in the dark and guess it was an Intel driver: glClear() gives GL_OUT_OF_MEMORY on Intel HD 4000 (GL 4.0) but not GeForce (GL 4.2)… why?: "Intel" plus "OpenGL" plus "strange problem" is sadly almost self-explanatory.. ouch, that hurts.

It would also be useful to know which version of "Windows" you were running, so r10894 will now also log this information. My guess is Windows 7 or Windows 8 (not 8.1) since SetProcessDPIAware() worked but SetProcessDPIAwareness did not.


initial scaling induced crash server info


How can you get the server info if it is crashed? How did you figure out it was crashed? Where is the server log? Can you not re-connect with a client? (xpra info is a client of sorts)


I run into the difficulty that my laptop has no numpad it looks like the +/= key of the OSX laptop keyboard is being read as plusminus by the server keymapping:


Just to clarify: since this is all running client-side, there is no "server keymapping". r10893 adds a plusminus shortcut for scaleup. Not sure if you managed to trigger scaledown with minus, if not please provide a keyname for the alternative OSX shortcut we want to use.


Laptops usually have a numlock somewhere, if not you can just define your own shortcut for the scaleup, scaledown and scalereset actions. See man page or:

$ xpra -h |& grep -A 11 shortcut


Perhaps a link through the tray/application menu for users with annoying keyboard layouts would be worth the effort? Maybe a control channel switch?


Both would be good to have... if I find the time.


PS: I have edited the log output to remove the Pillow debug bits - this is a side effect of the upgrade to Pillow 3, I will deal with that separately.


Sun, 18 Oct 2015 12:32:37 GMT - Antoine Martin:

r10900 ensures we don't continue to enlarge the window when we hit the maximum clamped scaling value (20 currently). On Windows 7 with an nvidia card this was triggering some WM_DWMCOMPOSITIONCHANGED events.

I suspect that the problem you hit might have been #942 instead: by doubling the window size every time, we must be reaching the OS / driver limits pretty quickly.


Tue, 20 Oct 2015 02:03:12 GMT - alas:

You are absolutely correct about the video driver -

OpenGL_accelerate module loaded
OpenGL properties:
* GLU extensions           : GL_EXT_bgra
* GLU version              : 1.2.2.0 Microsoft Corporation
* display_mode             : DOUBLE
* gdkgl.version            : 6.2
* gdkglext.version         : 1.2.0
* gtkglext.version         : 1.2.0
* has_alpha                : True
* max-viewport-dims        : (16384, 16384)
* opengl                   : 4.0
* pygdkglext.version       : 1.0.0
* pyopengl                 : 3.1.0
* renderer                 : Intel(R) HD Graphics 4000
* rgba                     : True
* safe                     : True
* shading language version : 4.00 - Build 10.18.10.3345
* texture-size-limit       : 16384
* vendor                   : Intel
* zerocopy                 : True

It is actually windows 8.1 that I'm testing with (bootcamped on a mac mini with the mac Intel graphics card).

Ohh, and I guess I was using the "server mapping" term wrong, I assume that there is a mapping of the client's keyboard, and then appropriate interpretation of the client side keystrokes by the server, according to the mapping. I assumed that the server saves that mapping somewhere, but I'm now guessing that I was wrong and it's the client that has the mapping, and just sends those keystrokes according to its own mapping interpretations to the server to "digest". I'll try not to confuse further with that.


initial scaling induced crash server info

I had to search to find this, thought I'd been meticulous to describe it as a client crash. Once I found what this was referring to, I laughed for a moment ... it would perhaps have been clearer with a comma: "initial scaling induced crash, server info" - that was the xpra info after the scaling induced the "initial client crash". Sorry about that.

I'm also unclear why the new 2x2 default, is it meant to be displaying windows at double the size to the client? (Maybe I'm just not sure why- when I connect, I then immediately end up downscaling, with shift-alt-minus, to get my windows back to matching the display size/resolution of the rest of my client side applications.)

It feels odd to have the default not try to match the sizing/dpi of the client's general settings.

In my case - initial connection lists:

2015-10-19 18:11:36,586  desktop size is 5120x2160 with 1 screen(s):
2015-10-19 18:11:36,586   Default (1354x571 mm - DPI: 96x96) workarea: 5120x2120
2015-10-19 18:11:36,586     DISPLAY1 3840x2160 at 1280x0 (621x341 mm - DPI: 157x160) workarea: 5120x2120
2015-10-19 18:11:36,586     DISPLAY2 1280x720 (597x336 mm - DPI: 54x54) workarea: 5120x2120
2015-10-19 18:11:36,586  scaled using 2 x 2 to:
2015-10-19 18:11:36,586   Default (1354x571 mm - DPI: 48x48) workarea: 2560x1060
2015-10-19 18:11:36,586     DISPLAY1 1920x1080 at 640x0 (621x341 mm - DPI: 78x80) workarea: 2560x1060
2015-10-19 18:11:36,586     DISPLAY2 640x360 (597x336 mm - DPI: 27x27) workarea: 2560x1060
2015-10-19 18:11:36,786 server: Linux Fedora 21 Twenty One, Xpra version 0.16.0-r10854

I then have to scale down to get it to match...

2015-10-19 18:12:05,936 sending updated screen size to server: 5120x2160 with 1 screens
2015-10-19 18:12:05,936   Default (1354x571 mm - DPI: 96x96) workarea: 5120x2120
2015-10-19 18:12:05,936     DISPLAY1 3840x2160 at 1280x0 (621x341 mm - DPI: 157x160) workarea: 5120x2120
2015-10-19 18:12:05,936     DISPLAY2 1280x720 (597x336 mm - DPI: 54x54) workarea: 5120x2120

Though, perhaps to answer my own question, the bandwidth is considerably lower if I use the 2x2 scaling to make the window contents larger rather than using the ctrl-+ functionality of the browser. (Maybe I'm just insane to leave the 4k at 4k resolution?)

And, while this maybe should be obvious, testing the combination of scaling +/- and using ctrl-+/- seems to have triggered a server crash (trying to repro isn't immediately successful though, so I couldn't confirm whether or not I just managed to use up all the server vm's resources):

[xcb] Unknown request in queue while dequeuing
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
python2: xcb_io.c:179: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed.
2015-10-19 18:20:25,391 sound-source stopping
Aborted (core dumped)


Tue, 20 Oct 2015 12:07:33 GMT - Antoine Martin:

It is actually windows 8.1 that I'm testing with (bootcamped on a mac mini with the mac Intel graphics card).


(expletives removed) - I'm going to have to install that thing somewhere, because my win32 DPI code looks borken: SetProcessDPIAwareness(1) failed: function 'SetProcessDPIAwareness' not found


.. I assumed that the server saves that mapping somewhere, but I'm now guessing that I was wrong and it's the client that has the mapping, and just sends those keystrokes according to its own mapping interpretations to the server to "digest". I'll try not to confuse further with that.


Actually, it's almost correct: the server has the mapping, but the client does almost no interpretation of the key events and just forwards them to the server, as raw as we can get them. Hence why when you report a client debug log, there is no server mapping involved at all.


I'm also unclear why the new 2x2 default, is it meant to be displaying windows at double the size to the client?


Yes. As per comment:4 : r10622 adds the "auto" mode, which will automatically enable scaling for client resolutions above 1080p: 150% up to WQXGA, 200% up to UHD, 300% for FUHD and 400% above that And "auto" is the now the default as per comment:15 : Since this works well enough, I have made "auto" mode the default in r10831. This is a big change. The point of this scaling is also covered in the ticket description and comments.


It feels odd to have the default not try to match the sizing/dpi of the client's general settings.


Unless there are DPI bugs, it should match: we report the screen size to the server as being smaller (half the width and height in your 4k test case) and so the DPI will be halved too (which we then double up when we re-upscale the window client side), so DPI aware applications should render at the same size as before, with somewhat bigger pixels but using a lot less bandwidth. xterm is not DPI aware, at least for its characters - the mouse cursor is handled differently though.


Maybe I'm just insane to leave the 4k at 4k resolution?


Most users will be running their 4k monitors at 4k resolution, this allows us to support them without completely hammering the server.



seems to have triggered a server crash


Indeed. If you can reproduce this one, a gdb backtrace would be very nice to have, it looks like a hard server crash that will need fixing. Edit: we now rate limit those scaling changes in r10919 but you can also change the rate limit using XPRA_SCALING_EMBARGO_TIME=DELAY where the delay is in milliseconds: using 0 would disable the new rate limiting code - potentially allowing you to more easily reproduce that crash.


Tue, 20 Oct 2015 22:09:29 GMT - alas:

Unless there are DPI bugs, it should match: we report the screen size to the server as being smaller (half the width and height in your 4k test case) and so the DPI will be halved too (which we then double up when we re-upscale the window client side), so DPI aware applications should render at the same size as before


Ok, I think I've finally pinned down why I was feeling like I was taking crazy pills. This description was what I thought the intention was, but looking at what's going on with tests on a 4k monitor, it looks like the opposite is what I'm seeing.

When I connect, the client side output is the following:

2015-10-20 10:18:55,039 Xpra gtk2 client version 0.16.0-r10921
2015-10-20 10:18:55,039  running on Microsoft Windows 8
2015-10-20 10:18:56,003 OpenGL_accelerate module loaded
2015-10-20 10:18:56,019 OpenGL enabled with Intel(R) HD Graphics 4000
2015-10-20 10:18:56,112 receiving data using AES encryption
2015-10-20 10:18:56,253 sending data using AES encryption
2015-10-20 10:18:56,346  detected keyboard: layout=us
2015-10-20 10:18:56,346  desktop size is 5120x2160 with 1 screen(s):
2015-10-20 10:18:56,346   Default (1354x571 mm - DPI: 96x96) workarea: 5120x2120
2015-10-20 10:18:56,346     DISPLAY1 3840x2160 at 1280x0 (621x341 mm - DPI: 157x160) workarea: 3840x2120
2015-10-20 10:18:56,346     DISPLAY2 1280x720 (597x336 mm - DPI: 54x54) workarea: 1280x680
2015-10-20 10:18:56,346  scaled using 2 x 2 to:
2015-10-20 10:18:56,346   Default (1354x571 mm - DPI: 48x48) workarea: 2560x1060
2015-10-20 10:18:56,346     DISPLAY1 1920x1080 at 640x0 (621x341 mm - DPI: 78x80) workarea: 1920x1060
2015-10-20 10:18:56,346     DISPLAY2 640x360 (597x336 mm - DPI: 27x27) workarea: 640x340
2015-10-20 10:18:56,815 server: Linux 4.1.5-100.fc21.x8664 Fedora 21 Twenty One, Xpra version 0.16.0-r10916

The initially acknowledged desktop size is correct, and per your description above ("we report the screen size to the server as being smaller (half the width and height in your 4k test case)"), I gather that the "scaled using 2 x 2 ..." is the lie the client is telling the server.

The server seems to be believing the lie:

2015-10-20 10:18:51,621  client root window size is 2560x1080 with 1 displays:
2015-10-20 10:18:51,621   Default (1354x571 mm - DPI: 48x48) workarea: 2560x1060
2015-10-20 10:18:51,621     DISPLAY1 1920x1080 at 640x0 (621x341 mm - DPI: 78x80) workarea: 1920x1060
2015-10-20 10:18:51,621     DISPLAY2 640x360 (597x336 mm - DPI: 27x27) workarea: 640x340
2015-10-20 10:18:51,879 server virtual display now set to 3200x1080 (best match for 2560x1080)
2015-10-20 10:18:51,881 setting key repeat rate from client: 500ms delay / 33ms interval
2015-10-20 10:18:51,882 setting keyboard layout to 'us'
2015-10-20 10:18:51,953 DPI set to 96 x 96

The problem seems to be that neither the server nor the client seems to then be taking that 2 x 2, DPI: 78x80 and scaling it back to the DPI: 157x160 display that I'm expecting - which is why I keep having to use shift-alt-minus to get it back to the display size I'm expecting.


Tue, 20 Oct 2015 22:14:58 GMT - alas: attachment set

desktop-scaling=auto 2x scaled on 4k window on left, local 157x160 DPI browser on right - don't match


Tue, 20 Oct 2015 22:36:55 GMT - alas:

I won't try to squeeze this scaled down image into the ticket, but the browser on the left in the screenshot is a scaled chromium, while the one on the right is a local chrome browser. The scaled xpra window seems to be displaying at 78x80 DPI listed in what I assumed was the lie to the server, while the local seems to be displaying at what I presume is the 157x160 DPI that is the pre-lie value indicated in client output - and if I use shift-alt-minus or shift-alt-*, the applications seem to display the same size, and client output indicates at that point that it is a 157x160 DPI display.

I also noticed that the client output is indicating running on Microsoft Windows 8, but checking shows that the local machine is convinced that it is running windows 8.1 Enterprise.


Testing with other resolutions/DPI settings, with the 4k pretending to be a 1080p, the auto setting doesn't scale, with 1920x1440 it scales at 1.5x, so it looks like the auto settings are triggering as expected (just not being "scaled back up to client DPI settings ... at 1.5x with the 1920x1440 the windows again displayed as if I'd lowered the resolution for them).


Haven't been able to repro the server crash, but I think I'd left the session running idle for a couple of days prior... so I'll try again to see if overnight is liable to help trigger.


Wed, 21 Oct 2015 01:13:39 GMT - alas:

Testing the osx laptop keyboard layout keys - osx 0.16.0 r10922 against 0.16.0 r10916 fedora 21 server:

... though, testing with both to see what the effect on the scaled windows would be, it looks like the control-plus/minus key combo is scaling the browser application (as expected), while the fn-alt is being interpreted as an alt key and working (or not working) as described above.

Checking with -d keyboard, the only difference I can see is that the control key has a keyval:65507, while the fn-alt has a keyval:65513.

Of course, testing the shift-alt-plus eventually also triggered a client crash:

2015-10-20 16:17:11,180 sending updated screen size to server: 4869x4096 with 1 screens
2015-10-20 16:17:11,180   schadenfreude.local (1044x878 mm - DPI: 118x118)
2015-10-20 16:17:11,180     monitor 1 2763x1727 at 2105x2368 (592x370 mm - DPI: 118x118)
2015-10-20 16:17:11,180     monitor 2 4211x2368 (903x508 mm - DPI: 118x118)
2015-10-20 16:18:00,542 sending updated screen size to server: 2434x2048 with 1 screens
2015-10-20 16:18:00,542   schadenfreude.local (1044x878 mm - DPI: 59x59)
2015-10-20 16:18:00,542     monitor 1 1381x863 at 1052x1184 (592x370 mm - DPI: 59x59)
2015-10-20 16:18:00,542     monitor 2 2105x1184 (903x508 mm - DPI: 59x59)
2015-10-20 16:18:03,606 sending updated screen size to server: 1217x1024 with 1 screens
2015-10-20 16:18:03,606   schadenfreude.local (1044x878 mm - DPI: 29x29)
2015-10-20 16:18:03,606     monitor 1 690x431 at 526x592 (592x370 mm - DPI: 29x29)
2015-10-20 16:18:03,606     monitor 2 1052x592 (903x508 mm - DPI: 29x29)
2015-10-20 16:18:22,845 sending updated screen size to server: 608x512 with 1 screens
2015-10-20 16:18:22,846   schadenfreude.local (1044x878 mm - DPI: 14x14)
2015-10-20 16:18:22,846     monitor 1 345x215 at 263x296 (592x370 mm - DPI: 14x14)
2015-10-20 16:18:22,846     monitor 2 526x296 (903x508 mm - DPI: 14x14)
2015-10-20 16:19:38,446 sending updated screen size to server: 1217x1024 with 1 screens
2015-10-20 16:19:38,446   schadenfreude.local (1044x878 mm - DPI: 29x29)
2015-10-20 16:19:38,447     monitor 1 690x431 at 526x592 (592x370 mm - DPI: 29x29)
2015-10-20 16:19:38,447     monitor 2 1052x592 (903x508 mm - DPI: 29x29)
2015-10-20 16:19:49,376 sending updated screen size to server: 2434x2048 with 1 screens
2015-10-20 16:19:49,377   schadenfreude.local (1044x878 mm - DPI: 59x59)
2015-10-20 16:19:49,377     monitor 1 1381x863 at 1052x1184 (592x370 mm - DPI: 59x59)
2015-10-20 16:19:49,377     monitor 2 2105x1184 (903x508 mm - DPI: 59x59)
2015-10-20 16:20:03,097 sending updated screen size to server: 1217x1024 with 1 screens
2015-10-20 16:20:03,097   schadenfreude.local (1044x878 mm - DPI: 29x29)
2015-10-20 16:20:03,097     monitor 1 690x431 at 526x592 (592x370 mm - DPI: 29x29)
2015-10-20 16:20:03,097     monitor 2 1052x592 (903x508 mm - DPI: 29x29)
/Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-16-10922/Xpra.app/Contents/Resources/lib/python/xpra/gtk_common/gtk_util.py:331: GtkWarning: gdk_colormap_get_visual: assertion 'GDK_IS_COLORMAP (colormap)' failed
Bus error: 10

It wasn't clear that this is another OpenGL issue, but I went ahead and grabbed the OpengGL info off this client as well (spoiler alert, it's an osx with an intel video card... I used --opengl=on out of habit, though I suppose it wasn't necessary):

OpenGL_accelerate module loaded
OpenGL properties:
* GLU extensions           :
* GLU version              : 1.3 MacOSX
* display_mode             : SINGLE
* gdkgl.version            : 1.0
* gdkglext.version         : 1.2.0
* gtkglext.version         : 1.2.0
* has_alpha                : True
* max-viewport-dims        : (16384, 16384)
* opengl                   : 2.1
* pygdkglext.version       : 1.0.0
* pyopengl                 : 3.1.1a1
* renderer                 : Intel Iris OpenGL Engine
* rgba                     : True
* safe                     : True
* shading language version : 1.20
* texture-size-limit       : 16384
* vendor                   : Intel Inc.
* zerocopy                 : True

Wed, 21 Oct 2015 03:39:30 GMT - Antoine Martin:

I also noticed that the client output is indicating running on Microsoft Windows 8, but checking shows that the local machine is convinced that it is running windows 8.1 Enterprise.


This has got to be the most epic fail I have ever seen from Microsoft (and they've had some astonishing ones already, but this one takes the cake). They broke it and introduced an API that is so bad, I had to check 3 times that this was not a joke. It isn't. There will be a workaround in Python 2.7.11: http://bugs.python.org/issue19143, so we will just have to wait for it.

The problem seems to be that neither the server nor the client seems to then be taking that 2 x 2, DPI: 78x80 and scaling it back to the DPI: 157x160 display that I'm expecting - which is why I keep having to use shift-alt-minus to get it back to the display size I'm expecting.


No. As can be seen in the output:

If the window contents look too big, then that's because the application being used is not honouring the DPI we set (and I would have expected this to be reported in #163). Minor fixes in r10928 and r10929, maybe this will help? If not, please see #163 for instructions on checking the server's DPI values, as there is more than one... Also note that some applications will only query the DPI on startup and will not re-adjust if the display geometry is changed afterwards.

Looking at the screenshot, the window contents are indeed bigger, but not by a factor of 2, more like 1.5 which is odd. Maybe the application is taking the DPI into account, but not using a linear scale as you would expect? We could change the heuristics to scale by 1.5 instead of 2.0 for 4k (please try it using the command line switch), and lower or none at all for lower resolutions, but maybe the application will use a different DPI then... testing will tell.


Of course, testing the shift-alt-plus eventually also triggered a client crash: (..) monitor 1 2763x1727 at 2105x2368 (592x370 mm - DPI: 118x118) monitor 2 4211x2368 (903x508 mm - DPI: 118x118)


Is this a real monitor?? Where did you find a monitor with such odd (literally) numbers of pixels?
What revision was this? Judging by the lack of scaling change rate throttling, this isn't the latest? Can you also trigger this crash by toggling opengl on and off repeatedly, or only when scaling up and down repeatedly? Unlike the win32 crash, this one is not happening at the highest scaling possible (you had a 14x14 DPI higher up in the log). It looks like scaling by 8 is the limit on this particular system, but it would be good to know the limit on more systems so we can come up with a hard limit that is unlikely to ever trigger a crash.


It wasn't clear that this is another OpenGL issue, ...


Right, and maybe it isn't:


The cursor size problem should now be fixed in r10941 (+r10942 for applications start with start / start-child), we needed to:


Thu, 22 Oct 2015 02:12:19 GMT - alas:

I was testing with the latest OSX client I could lay my hands on when I produced that crash - 0.16.0 r10922 (our build, against a 0.16.0 r10916 fedora 21 server from your repo).

I was also able to produce another crash with --opengl=off and only using the laptop display (taking stock of my usual machines for testing, I realize that they are all running with Intel graphics cards... the horror)... and the crash triggered an OSX Problem Report & traceback (I'll also include some of the desktop size change output prior):

2015-10-21 17:32:05,096 sending updated screen size to server: 840x525 with 1 screens
2015-10-21 17:32:05,096   schadenfreude.local (592x370 mm - DPI: 36x36)
2015-10-21 17:32:05,096     monitor 1
2015-10-21 17:32:18,553 sending updated screen size to server: 1680x1050 with 1 screens
2015-10-21 17:32:18,553   schadenfreude.local (592x370 mm - DPI: 72x72)
2015-10-21 17:32:18,553     monitor 1
2015-10-21 17:36:34,428 sending updated screen size to server: 840x525 with 1 screens
2015-10-21 17:36:34,428   schadenfreude.local (592x370 mm - DPI: 36x36)
2015-10-21 17:36:34,428     monitor 1
2015-10-21 17:37:24,168 sending updated screen size to server: 420x262 with 1 screens
2015-10-21 17:37:24,169   schadenfreude.local (592x370 mm - DPI: 18x17)
2015-10-21 17:37:24,169     monitor 1
2015-10-21 17:37:39,615 sending updated screen size to server: 210x131 with 1 screens
2015-10-21 17:37:39,615   schadenfreude.local (592x370 mm - DPI: 9x8)
2015-10-21 17:37:39,616     monitor 1
2015-10-21 17:37:40,521 UI thread is now blocked
2015-10-21 17:37:45,819 UI thread is running again, resuming
2015-10-21 17:37:46.489 xpra[38150:d0b] _NXPlaceWindow: error setting window shape (1000)
2015-10-21 17:37:46.490 xpra[38150:d0b] _NSShapeRoundedWindowWithWeighting: error setting window shape (1000)
2015-10-21 17:38:07,064 sending updated screen size to server: 105x65 with 1 screens
2015-10-21 17:38:07,064   schadenfreude.local (592x370 mm - DPI: 4x4)
2015-10-21 17:38:07,064     monitor 1
2015-10-21 17:38:07.329 xpra[38150:d0b] An uncaught exception was raised
2015-10-21 17:38:07.332 xpra[38150:d0b] Error (1007) creating CGSWindow on line 263
2015-10-21 17:38:07.349 xpra[38150:d0b] (
	0   CoreFoundation                      0x925d1471 __raiseError + 193
	1   libobjc.A.dylib                     0x92c24091 objc_exception_throw + 162
	2   CoreFoundation                      0x925d138b +[NSException raise:format:] + 139
	3   AppKit                              0x94ceaf23 _NSCreateWindowWithOpaqueShape2 + 1718
	4   AppKit                              0x94ce99aa -[NSWindow _commonAwake] + 4391
	5   AppKit                              0x94bbe56b -[NSWindow _commonInitFrame:styleMask:backing:defer:] + 864
	6   AppKit                              0x94bbdb53 -[NSWindow _initContent:styleMask:backing:defer:contentView:] + 1090
	7   AppKit                              0x94bbd70a -[NSWindow initWithContentRect:styleMask:backing:defer:] + 70
	8   AppKit                              0x953b24b0 -[NSWindow initWithContentRect:styleMask:backing:defer:screen:] + 79
	9   libgdk-quartz-2.0.0.dylib           0x02f03ef6 -[GdkQuartzWindow initWithContentRect:styleMask:backing:defer:screen:] + 118
	10  libgdk-quartz-2.0.0.dylib           0x02f187c2 _gdk_window_impl_new + 1066
	11  libgdk-quartz-2.0.0.dylib           0x02ef00da gdk_window_new + 1265
	12  libgtk-quartz-2.0.0.dylib           0x02ca9452 gtk_window_realize + 918
	13  libgobject-2.0.0.dylib              0x0330ef08 g_cclosure_marshal_VOID__VOID + 170
	14  libgobject-2.0.0.dylib              0x0330c7d5 g_type_class_meta_marshal + 97
	15  libgobject-2.0.0.dylib              0x0330c17a g_closure_invoke + 366
	16  libgobject-2.0.0.dylib              0x03325c9f signal_emit_unlocked_R + 597
	17  libgobject-2.0.0.dylib              0x033254ad g_signal_emit_valist + 3568
	18  libgobject-2.0.0.dylib              0x0332590b g_signal_emit + 44
	19  libgtk-quartz-2.0.0.dylib           0x02c912b8 gtk_widget_realize + 446
	20  libgtk-quartz-2.0.0.dylib           0x02ca8b43 gtk_window_show + 293
	21  libgobject-2.0.0.dylib              0x0330ef77 g_cclosure_marshal_VOID__VOIDv + 105
	22  libgobject-2.0.0.dylib              0x0330c840 g_type_class_meta_marshalv + 105
	23  libgobject-2.0.0.dylib              0x0330c401 _g_closure_invoke_va + 375
	24  libgobject-2.0.0.dylib              0x03324c6f g_signal_emit_valist + 1458
	25  libgobject-2.0.0.dylib              0x0332590b g_signal_emit + 44
	26  libgtk-quartz-2.0.0.dylib           0x02c907eb gtk_widget_show + 219
	27  _gtk.so                             0x03ce6c15 _wrap_gtk_widget_show + 46
	28  libpython2.7.dylib                  0x00011575 PyObject_Call + 85
	29  libpython2.7.dylib                  0x000c01fe PyEval_CallObjectWithKeywords + 78
	30  libpython2.7.dylib                  0x0002f794 methoddescr_call + 260
	31  libpython2.7.dylib                  0x00011575 PyObject_Call + 85
	32  libpython2.7.dylib                  0x000c2a24 PyEval_EvalFrameEx + 5556
	33  libpython2.7.dylib                  0x000c96cf PyEval_EvalFrameEx + 33375
	34  libpython2.7.dylib                  0x000c9f4c PyEval_EvalCodeEx + 2012
	35  libpython2.7.dylib                  0x000434bb function_call + 139
	36  libpython2.7.dylib                  0x00011575 PyObject_Call + 85
	37  libpython2.7.dylib                  0x00022d5e instancemethod_call + 350
	38  libpython2.7.dylib                  0x00011575 PyObject_Call + 85
	39  libpython2.7.dylib                  0x000c4656 PyEval_EvalFrameEx + 12774
	40  libpython2.7.dylib                  0x000c9f4c PyEval_EvalCodeEx + 2012
	41  libpython2.7.dylib                  0x000c7cdb PyEval_EvalFrameEx + 26731
	42  libpython2.7.dylib                  0x000c9f4c PyEval_EvalCodeEx + 2012
	43  libpython2.7.dylib                  0x000c7cdb PyEval_EvalFrameEx + 26731
	44  libpython2.7.dylib                  0x000c9f4c PyEval_EvalCodeEx + 2012
	45  libpython2.7.dylib                  0x000c7cdb PyEval_EvalFrameEx + 26731
	46  libpython2.7.dylib                  0x000c9f4c PyEval_EvalCodeEx + 2012
	47  libpython2.7.dylib                  0x000c7cdb PyEval_EvalFrameEx + 26731
	48  libpython2.7.dylib                  0x000c96cf PyEval_EvalFrameEx + 33375
	49  libpython2.7.dylib                  0x000c9f4c PyEval_EvalCodeEx + 2012
	50  libpython2.7.dylib                  0x000434bb function_call + 139
	51  libpython2.7.dylib                  0x00011575 PyObject_Call + 85
	52  libpython2.7.dylib                  0x000c4656 PyEval_EvalFrameEx + 12774
	53  libpython2.7.dylib                  0x000c96cf PyEval_EvalFrameEx + 33375
	54  libpython2.7.dylib                  0x000c96cf PyEval_EvalFrameEx + 33375
	55  libpython2.7.dylib                  0x000c96cf PyEval_EvalFrameEx + 33375
	56  libpython2.7.dylib                  0x000c9f4c PyEval_EvalCodeEx + 2012
	57  libpython2.7.dylib                  0x000434bb function_call + 139
	58  libpython2.7.dylib                  0x00011575 PyObject_Call + 85
	59  libpython2.7.dylib                  0x00022d5e instancemethod_call + 350
	60  libpython2.7.dylib                  0x00011575 PyObject_Call + 85
	61  libpython2.7.dylib                  0x000c01fe PyEval_CallObjectWithKeywords + 78
	62  libpython2.7.dylib                  0x00011620 PyObject_CallObject + 32
	63  _gtk.so                             0x03cf9ee7 _wrap_GtkWidget__proxy_do_key_press_event + 370
	64  libgtk-quartz-2.0.0.dylib           0x02b1dc39 _gtk_marshal_BOOLEAN__BOXED + 225
	65  libgobject-2.0.0.dylib              0x0330c7d5 g_type_class_meta_marshal + 97
	66  libgobject-2.0.0.dylib              0x0330c17a g_closure_invoke + 366
	67  libgobject-2.0.0.dylib              0x03326085 signal_emit_unlocked_R + 1595
	68  libgobject-2.0.0.dylib              0x0332554b g_signal_emit_valist + 3726
	69  libgobject-2.0.0.dylib              0x0332590b g_signal_emit + 44
	70  libgtk-quartz-2.0.0.dylib           0x02c93d2d gtk_widget_event_internal + 846
	71  libgtk-quartz-2.0.0.dylib           0x02c937ac gtk_widget_event + 283
	72  libgtk-quartz-2.0.0.dylib           0x02b1c147 gtk_propagate_event + 519
	73  libgtk-quartz-2.0.0.dylib           0x02b1ac77 gtk_main_do_event + 1211
	74  libgdk-quartz-2.0.0.dylib           0x02f0a692 gdk_event_dispatch + 130
	75  libglib-2.0.0.dylib                 0x0338f8d5 g_main_dispatch + 393
	76  libglib-2.0.0.dylib                 0x033905f0 g_main_context_dispatch + 41
	77  libglib-2.0.0.dylib                 0x033907cf g_main_context_iterate + 466
	78  libglib-2.0.0.dylib                 0x03390c01 g_main_loop_run + 476
	79  libgtk-quartz-2.0.0.dylib           0x02b1a127 gtk_main + 239
	80  _gtk.so                             0x03e221af _wrap_gtk_main + 129
	81  libpython2.7.dylib                  0x000c75ab PyEval_EvalFrameEx + 24891
	82  libpython2.7.dylib                  0x000c96cf PyEval_EvalFrameEx + 33375
	83  libpython2.7.dylib                  0x000c96cf PyEval_EvalFrameEx + 33375
	84  libpython2.7.dylib                  0x000c96cf PyEval_EvalFrameEx + 33375
	85  libpython2.7.dylib                  0x000c96cf PyEval_EvalFrameEx + 33375
	86  libpython2.7.dylib                  0x000c9f4c PyEval_EvalCodeEx + 2012
	87  libpython2.7.dylib                  0x000c7cdb PyEval_EvalFrameEx + 26731
	88  libpython2.7.dylib                  0x000c96cf PyEval_EvalFrameEx + 33375
	89  libpython2.7.dylib                  0x000c96cf PyEval_EvalFrameEx + 33375
	90  libpython2.7.dylib                  0x000c9f4c PyEval_EvalCodeEx + 2012
	91  libpython2.7.dylib                  0x000ca097 PyEval_EvalCode + 87
	92  libpython2.7.dylib                  0x000ef73d PyRun_StringFlags + 285
	93  libpython2.7.dylib                  0x000ef84e PyRun_SimpleStringFlags + 78
	94  libpython2.7.dylib                  0x00106a0c Py_Main + 1564
	95  xpra                                0x00002fb6 start + 54
)
2015-10-21 17:38:07.351 xpra[38150:d0b] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Error (1007) creating CGSWindow on line 263'
*** Call stack at first throw:
(
	0   CoreFoundation                      0x925d1471 __raiseError + 193
	1   libobjc.A.dylib                     0x92c24091 objc_exception_throw + 162
	2   CoreFoundation                      0x925d138b +[NSException raise:format:] + 139
	3   AppKit                              0x94ceaf23 _NSCreateWindowWithOpaqueShape2 + 1718
	4   AppKit                              0x94ce99aa -[NSWindow _commonAwake] + 4391
	5   AppKit                              0x94bbe56b -[NSWindow _commonInitFrame:styleMask:backing:defer:] + 864
	6   AppKit                              0x94bbdb53 -[NSWindow _initContent:styleMask:backing:defer:contentView:] + 1090
	7   AppKit                              0x94bbd70a -[NSWindow initWithContentRect:styleMask:backing:defer:] + 70
	8   AppKit                              0x953b24b0 -[NSWindow initWithContentRect:styleMask:backing:defer:screen:] + 79
	9   libgdk-quartz-2.0.0.dylib           0x02f03ef6 -[GdkQuartzWindow initWithContentRect:styleMask:backing:defer:screen:] + 118
	10  libgdk-quartz-2.0.0.dylib           0x02f187c2 _gdk_window_impl_new + 1066
	11  libgdk-quartz-2.0.0.dylib           0x02ef00da gdk_window_new + 1265
	12  libgtk-quartz-2.0.0.dylib           0x02ca9452 gtk_window_realize + 918
	13  libgobject-2.0.0.dylib              0x0330ef08 g_cclosure_marshal_VOID__VOID + 170
	14  libgobject-2.0.0.dylib              0x0330c7d5 g_type_class_meta_marshal + 97
	15  libgobject-2.0.0.dylib              0x0330c17a g_closure_invoke + 366
	16  libgobject-2.0.0.dylib              0x03325c9f signal_emit_unlocked_R + 597
	17  libgobject-2.0.0.dylib              0x033254ad g_signal_emit_valist + 3568
	18  libgobject-2.0.0.dylib              0x0332590b g_signal_emit + 44
	19  libgtk-quartz-2.0.0.dylib           0x02c912b8 gtk_widget_realize + 446
	20  libgtk-quartz-2.0.0.dylib           0x02ca8b43 gtk_window_show + 293
	21  libgobject-2.0.0.dylib              0x0330ef77 g_cclosure_marshal_VOID__VOIDv + 105
	22  libgobject-2.0.0.dylib              0x0330c840 g_type_class_meta_marshalv + 105
	23  libgobject-2.0.0.dylib              0x0330c401 _g_closure_invoke_va + 375
	24  libgobject-2.0.0.dylib              0x03324c6f g_signal_emit_valist + 1458
	25  libgobject-2.0.0.dylib              0x0332590b g_signal_emit + 44
	26  libgtk-quartz-2.0.0.dylib           0x02c907eb gtk_widget_show + 219
	27  _gtk.so                             0x03ce6c15 _wrap_gtk_widget_show + 46
	28  libpython2.7.dylib                  0x00011575 PyObject_Call + 85
	29  libpython2.7.dylib                  0x000c01fe PyEval_CallObjectWithKeywords + 78
	30  libpython2.7.dylib                  0x0002f794 methoddescr_call + 260
	31  libpython2.7.dylib                  0x00011575 PyObject_Call + 85
	32  libpython2.7.dylib                  0x000c2a24 PyEval_EvalFrameEx + 5556
	33  libpython2.7.dylib                  0x000c96cf PyEval_EvalFrameEx + 33375
	34  libpython2.7.dylib                  0x000c9f4c PyEval_EvalCodeEx + 2012
	35  libpython2.7.dylib                  0x000434bb function_call + 139
	36  libpython2.7.dylib                  0x00011575 PyObject_Call + 85
	37  libpython2.7.dylib                  0x00022d5e instancemethod_call + 350
	38  libpython2.7.dylib                  0x00011575 PyObject_Call + 85
	39  libpython2.7.dylib                  0x000c4656 PyEval_EvalFrameEx + 12774
	40  libpython2.7.dylib                  0x000c9f4c PyEval_EvalCodeEx + 2012
	41  libpython2.7.dylib                  0x000c7cdb PyEval_EvalFrameEx + 26731
	42  libpython2.7.dylib                  0x000c9f4c PyEval_EvalCodeEx + 2012
	43  libpython2.7.dylib                  0x000c7cdb PyEval_EvalFrameEx + 26731
	44  libpython2.7.dylib                  0x000c9f4c PyEval_EvalCodeEx + 2012
	45  libpython2.7.dylib                  0x000c7cdb PyEval_EvalFrameEx + 26731
	46  libpython2.7.dylib                  0x000c9f4c PyEval_EvalCodeEx + 2012
	47  libpython2.7.dylib                  0x000c7cdb PyEval_EvalFrameEx + 26731
	48  libpython2.7.dylib                  0x000c96cf PyEval_EvalFrameEx + 33375
	49  libpython2.7.dylib                  0x000c9f4c PyEval_EvalCodeEx + 2012
	50  libpython2.7.dylib                  0x000434bb function_call + 139
	51  libpython2.7.dylib                  0x00011575 PyObject_Call + 85
	52  libpython2.7.dylib                  0x000c4656 PyEval_EvalFrameEx + 12774
	53  libpython2.7.dylib                  0x000c96cf PyEval_EvalFrameEx + 33375
	54  libpython2.7.dylib                  0x000c96cf PyEval_EvalFrameEx + 33375
	55  libpython2.7.dylib                  0x000c96cf PyEval_EvalFrameEx + 33375
	56  libpython2.7.dylib                  0x000c9f4c PyEval_EvalCodeEx + 2012
	57  libpython2.7.dylib                  0x000434bb function_call + 139
	58  libpython2.7.dylib                  0x00011575 PyObject_Call + 85
	59  libpython2.7.dylib                  0x00022d5e instancemethod_call + 350
	60  libpython2.7.dylib                  0x00011575 PyObject_Call + 85
	61  libpython2.7.dylib                  0x000c01fe PyEval_CallObjectWithKeywords + 78
	62  libpython2.7.dylib                  0x00011620 PyObject_CallObject + 32
	63  _gtk.so                             0x03cf9ee7 _wrap_GtkWidget__proxy_do_key_press_event + 370
	64  libgtk-quartz-2.0.0.dylib           0x02b1dc39 _gtk_marshal_BOOLEAN__BOXED + 225
	65  libgobject-2.0.0.dylib              0x0330c7d5 g_type_class_meta_marshal + 97
	66  libgobject-2.0.0.dylib              0x0330c17a g_closure_invoke + 366
	67  libgobject-2.0.0.dylib              0x03326085 signal_emit_unlocked_R + 1595
	68  libgobject-2.0.0.dylib              0x0332554b g_signal_emit_valist + 3726
	69  libgobject-2.0.0.dylib              0x0332590b g_signal_emit + 44
	70  libgtk-quartz-2.0.0.dylib           0x02c93d2d gtk_widget_event_internal + 846
	71  libgtk-quartz-2.0.0.dylib           0x02c937ac gtk_widget_event + 283
	72  libgtk-quartz-2.0.0.dylib           0x02b1c147 gtk_propagate_event + 519
	73  libgtk-quartz-2.0.0.dylib           0x02b1ac77 gtk_main_do_event + 1211
	74  libgdk-quartz-2.0.0.dylib           0x02f0a692 gdk_event_dispatch + 130
	75  libglib-2.0.0.dylib                 0x0338f8d5 g_main_dispatch + 393
	76  libglib-2.0.0.dylib                 0x033905f0 g_main_context_dispatch + 41
	77  libglib-2.0.0.dylib                 0x033907cf g_main_context_iterate + 466
	78  libglib-2.0.0.dylib                 0x03390c01 g_main_loop_run + 476
	79  libgtk-quartz-2.0.0.dylib           0x02b1a127 gtk_main + 239
	80  _gtk.so                             0x03e221af _wrap_gtk_main + 129
	81  libpython2.7.dylib                  0x000c75ab PyEval_EvalFrameEx + 24891
	82  libpython2.7.dylib                  0x000c96cf PyEval_EvalFrameEx + 33375
	83  libpython2.7.dylib                  0x000c96cf PyEval_EvalFrameEx + 33375
	84  libpython2.7.dylib                  0x000c96cf PyEval_EvalFrameEx + 33375
	85  libpython2.7.dylib                  0x000c96cf PyEval_EvalFrameEx + 33375
	86  libpython2.7.dylib                  0x000c9f4c PyEval_EvalCodeEx + 2012
	87  libpython2.7.dylib                  0x000c7cdb PyEval_EvalFrameEx + 26731
	88  libpython2.7.dylib                  0x000c96cf PyEval_EvalFrameEx + 33375
	89  libpython2.7.dylib                  0x000c96cf PyEval_EvalFrameEx + 33375
	90  libpython2.7.dylib                  0x000c9f4c PyEval_EvalCodeEx + 2012
	91  libpython2.7.dylib                  0x000ca097 PyEval_EvalCode + 87
	92  libpython2.7.dylib                  0x000ef73d PyRun_StringFlags + 285
	93  libpython2.7.dylib                  0x000ef84e PyRun_SimpleStringFlags + 78
	94  libpython2.7.dylib                  0x00106a0c Py_Main + 1564
	95  xpra                                0x00002fb6 start + 54
)
Trace/BPT trap: 5
Schadenfreude:MacOS Schadenfreude$ 2015-10-21 17:38:07,907 sound-sink stopping

Testing some of those issues with the key shortcuts, I noticed that the laptop, when using "fn-option/alt" in place of alt, seemed to also be triggering some of the OSX versions of the key-sym shortcuts:

So, using --key-shortcut=Meta+Shift+emdash:scaledown & --key-shortcut=Meta+Shift+degree:scalereset seems to be working to use what looks like a - and a * with the shift-alt to produce effects similar to the ones with a numpad.

However, it looks like the fn-option/alt is sometimes triggering, with browsers, zooming (I'll continue to chase that one down, maybe I was just doing something silly while distracted).


As for the dimensions of those monitors - I'm not sure what happened to those values. Scaling up and down and all around seemed to be producing some extremely strange values (the default dpi when I connect with just the laptop display is 72x72, and when I connect with the second monitor connected it scales 2x2 and uses 36x36... maybe I happened to also be trying some other --desktop-scaling= value?). Unfortunately, scaling up often sizes up applications to the point where they cover the entire display, so I'm not sure what the values are doing until I look at the command line later.

Also worth mentioning, when I launch other applications (google-chrome, firefox, epiphany, gedit) from an xterm on a scaled client (due to new defaults with large workspace) - they all seem to also be unwilling to respect the scaling back up that the client is supposed to be doing.

I'll do more testing of the DPI (per #163) and include any further info on that issue there.


Thu, 22 Oct 2015 03:35:31 GMT - Antoine Martin:

I was testing with the latest OSX client I could lay my hands on when I produced that crash - 0.16.0 r10922 (our build, against a 0.16.0 r10916 fedora 21 server from your repo).


It would be good to know if the crash was caused by the scaling, or by the window becoming too big. Testing with a newer client would help. In any case r10950 now limits upscaling to 8 times, as going above that is what triggers crashes on win32 and osx. Hopefully this limit is now low enough to avoid crashes on all platform + card combinations.

Thanks for the new osx shortcuts, added in r10951.

However, it looks like the fn-option/alt is sometimes triggering, with browsers, zooming (I'll continue to chase that one down, maybe I was just doing something silly while distracted).


Ouch. Browsers often scale up/down with control + plus/minus. Maybe Alt is being dropped, and so we don't intercept the key combo as a shortcut and pass it to the browser..


maybe I happened to also be trying some other --desktop-scaling= value?


Yes, that must be it.


Also worth mentioning, when I launch other applications .. they all seem to also be unwilling to respect the scaling back up that the client is supposed to be doing.


r10953, r10966 and r10970 should fix that: the "hardware" dpi was correctly updated, but the xsettings one was not (I thought google-chrome was using the "hardware" one? maybe not then) r10967 changes by how much we adjust the scaling using the key shortcuts (was 100% increase, now just 50% at a time)

Simple apps like gnome-calculator and most of our GTK test apps do seem to adjust to the new DPI settings.

If you find that with the default scaling factor (or even with a custom one), the browser rendering is very different - it would be worth taking a snapshot of a local and remote browser side by side showing the same page to see by how much things are diverging - and if this is the same ratio as the scaling factor. (say a fixed size picture, some font, a youtube video, etc..)


Sat, 24 Oct 2015 00:22:40 GMT - alas:

Hmm... testing with osx 0.16.0 r10972 I was getting decoding problems (#1010), but ignoring those, I decided to try changing the screen resolution values (through System Preferences menu) up and down to see what would happen with the resolution of the applications (especially chromium).

It seemed like the content of the chromium window was not changing resolution, though oddly the window itself kept resizing as if I had maximized it with every local resolution change.

After a number of screen resolution changes, and attendant workarea changes, the client crashed (seemed stable enough despite the decoding errors in #1010, leading me to suspect crash is related to the resolution changes). Here are some of the size changes, and some of the tracebacks (editing to remove some repetitions):

Traceback (most recent call last):
  File "/Users/osx/gtk/inst/lib/python2.7/site-packages/xpra/client/gtk_base/gtk_client_window_base.py", line 275, in on_realize
  File "/Users/osx/gtk/inst/lib/python2.7/site-packages/xpra/gtk_common/gobject_compat.py", line 62, in get_xid
AttributeError: xid attribute not supported
2015-10-23 15:17:11,255 server is not responding, drawing spinners over the windows
2015-10-23 15:17:23,086 server is OK again
2015-10-23 15:17:36,851 sending updated screen size to server: 1920x1680 with 1 screens
2015-10-23 15:17:36,851   schadenfreude.local (903x790 mm - DPI: 54x54)
2015-10-23 15:17:36,851     monitor 1 960x600 at 960x1080 (451x282 mm - DPI: 54x54)
2015-10-23 15:17:36,852     monitor 2 1920x1080 (903x508 mm - DPI: 54x54)
2015-10-23 15:17:36,852 screen size change: will reinit the windows
...
2015-10-23 15:18:14,130 sending updated screen size to server: 2040x1755 with 1 screens
2015-10-23 15:18:14,131   schadenfreude.local (959x825 mm - DPI: 54x54)
2015-10-23 15:18:14,131     monitor 1 1080x675 at 960x1080 (508x317 mm - DPI: 54x54)
2015-10-23 15:18:14,131     monitor 2 1920x1080 (903x508 mm - DPI: 54x54)
2015-10-23 15:18:14,131 screen size change: will reinit the windows
...
2015-10-23 15:18:53,842 sending updated screen size to server: 2220x1867 with 1 screens
2015-10-23 15:18:53,842   schadenfreude.local (1044x878 mm - DPI: 54x54)
2015-10-23 15:18:53,843     monitor 1 1260x787 at 960x1080 (592x370 mm - DPI: 54x54)
2015-10-23 15:18:53,843     monitor 2 1920x1080 (903x508 mm - DPI: 54x54)
2015-10-23 15:18:53,843 screen size change: will reinit the windows
2015-10-23 15:18:53,872 get_window_frame_sizes()={'frame': (0, 0, 22, 0), 'offset': (0, 22)}
Traceback (most recent call last):
  File "/Users/osx/gtk/inst/lib/python2.7/site-packages/xpra/client/gtk_base/gtk_client_window_base.py", line 275, in on_realize
  File "/Users/osx/gtk/inst/lib/python2.7/site-packages/xpra/gtk_common/gobject_compat.py", line 62, in get_xid
AttributeError: xid attribute not supported
Bus error: 10
Schadenfreude:MacOS Schadenfreude$ 2015-10-23 15:18:54,978 sound-sink stopping

Repro'ing rather easily, I got a different traceback:

2015-10-23 17:19:30,338 sending updated screen size to server: 2960x1950 with 1 screens
2015-10-23 17:19:30,338   schadenfreude.local (1044x687 mm - DPI: 72x72)
2015-10-23 17:19:30,339     monitor 1 1680x1050 at 1280x900 (592x370 mm - DPI: 72x72)
2015-10-23 17:19:30,339     monitor 2 1600x900 (564x317 mm - DPI: 72x72)
2015-10-23 17:19:30,339 screen size change: will reinit the windows
/Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-16-10972/Xpra.app/Contents/Resources/lib/python/xpra/client/gl/gl_window_backing_base.py:433: Warning: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
/Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-16-10972/Xpra.app/Contents/Resources/lib/python/xpra/client/gl/gl_window_backing_base.py:434: Warning: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
/Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-16-10972/Xpra.app/Contents/Resources/lib/python/xpra/client/gl/gtk_compat.py:101: GtkWarning: gtk_widget_set_colormap: assertion 'GDK_IS_COLORMAP (colormap)' failed
/Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-16-10972/Xpra.app/Contents/Resources/lib/python/xpra/client/gtk_base/gtk_client_window_base.py:321: GtkWarning: gdk_colormap_get_visual: assertion 'GDK_IS_COLORMAP (colormap)' failed
Bus error: 10
Schadenfreude:MacOS Schadenfreude$ 2015-10-23 17:19:30,863 sound-sink stopping

Sat, 24 Oct 2015 04:17:17 GMT - Antoine Martin:

The scaling changes should trigger exactly the same code as the "screen size change": in both cases we re-init the windows... But if the crash from comment:28 only ever occurs with "screen size change" then it should go in a new ticket. (one I have no idea how I would fix - but maybe this a regression? in which case we could do something)

Minor fixup for handling window move/resize in r11029.


Tue, 27 Oct 2015 16:23:54 GMT - Antoine Martin:

Another important fix: r11058, triggered by testing with browser/xpra/trunk/src/tests/xpra/test_apps/test_window_moveresize.py as part of testing for #990... (confused me for hours thinking there was a bug in the changes from #990). So it is worth testing with more of those test applications to find corner cases.


Wed, 28 Oct 2015 00:05:08 GMT - alas:

Well, with windows client 0.16.0 r10983, against 0.16.0 r11031 fedora 21 server, I went back through the dpi tests listed in both #163 & #697 - but all dpi and client.screen checks seemed to be in agreement with the desktop & display info output by both client and server upon each re-init.

I'll have to dig deeper to see if I can find more info about application dpi settings, I guess... to see why the windows and content still seem larger than local applications.

Will build some new clients to re-test for comment:29 & comment:30 soon as well.


Fri, 30 Oct 2015 06:19:18 GMT - Antoine Martin:

r11089 (+ r11094 for osx) makes it a little bit easier to test scaling by adding a tray menu entry to choose scaling values, those scaling values can be overriden with:

XPRA_TRAY_SCALING_OPTIONS=0.4,0.5,2.0,4.0 xpra attach ..

(note: the values are floating point numbers, which we show to the user as percentages - maybe the command line should take percentages too?)

Be aware of #559. Sub pixel rendering will help smooth things when upscaling. (and this ticket doesn't look like it really got tested properly)


Thu, 05 Nov 2015 23:44:06 GMT - alas:

Hmmm... scaling up a session with just a pair of xterms (re-testing #559 a bit), I'm seeing the following traceback on windows 8.1 client 0.16.0 r11122 (against same revision fedora 21 server):

  2015-11-05 15:29:18,789 draw error
Traceback (most recent call last):
  File "xpra\client\ui_client_base.pyc", line 2493, in _do_draw
  File "xpra\client\client_window_base.pyc", line 540, in draw_region
  File "xpra\client\window_backing_base.pyc", line 521, in draw_region
  File "xpra\client\window_backing_base.pyc", line 301, in paint_rgb32
  File "xpra\client\window_backing_base.pyc", line 180, in process_delta
Exception: delta region bucket 0 references pixmap data we do not have!
2015-11-05 15:29:18,789 error processing draw packet

It is being reliably triggered when I start with --encodings=rgb and get the client scaled to:

2015-11-05 15:29:18,576 get_workareas()=[(0, 0, 3840, 2120), (0, 0, 1280, 680)]
2015-11-05 15:29:18,576 get_workarea() absolute total monitor area: (-1280, 0, 3840, 2160)
2015-11-05 15:29:18,576  total monitor dimensions: (5120, 2160)
2015-11-05 15:29:18,576 sending updated screen size to server: 1137x480 with 1 screens
2015-11-05 15:29:18,576   Default (1354x571 mm - DPI: 21x21) workarea: 1137x471
2015-11-05 15:29:18,576     DISPLAY1 853x480 at 284x0 (621x341 mm - DPI: 34x35) workarea: 853x471
2015-11-05 15:29:18,576     DISPLAY2 284x160 (597x336 mm - DPI: 12x12) workarea: 284x151

I couldn't repro with --encodings=jpg or webp.

... ohh, and, in case it matters, I had XPRA_OPENGL_PAINT_POX=1 set.


Fri, 06 Nov 2015 02:01:31 GMT - Antoine Martin:

Yes, I have seen those "delta region bucket XXX references pixmap data we do not have!" (this can happen with any encoding set if we end up actually using rgb), it's a tricky one to fix as we re-create the windows whilst the server is sending us screen updates, things easily get out of sync. The server will just re-send a new screen update, so I am not going to worry too much about for now.


Sun, 08 Nov 2015 15:36:50 GMT - Antoine Martin:

Note: r11151 fixes windows 8.1 onwards "DPI awareness".


Tue, 10 Nov 2015 05:09:22 GMT - Antoine Martin:

r11162 fixes the resizing loops caused by coordinates rounding, also disables scaling when connecting to older servers and when using mmap.


Wed, 11 Nov 2015 00:07:04 GMT - alas:

Glad I saw that message - stumbled across the resizing loop and was just getting ready to make a ticket.

Installed 0.16.0 r11176 windows client and 0.16.0 r11152 (which was pulled from the winswitch.beta repo) - and got the following warning client side:

2015-11-10 10:52:58,446  desktop size is 5120x2160 with 1 screen(s):
2015-11-10 10:52:58,446   Default (1354x571 mm - DPI: 96x96) workarea: 5120x2120
2015-11-10 10:52:58,446     DISPLAY1 3840x2160 at 1280x0 (621x341 mm - DPI: 157x160) workarea: 3840x2120
2015-11-10 10:52:58,446     DISPLAY2 1280x720 (597x336 mm - DPI: 54x54) workarea: 1280x680
2015-11-10 10:52:58,446  scaled using 2 x 2 to: 2560x1080
2015-11-10 10:52:58,446   Default (1354x571 mm - DPI: 48x48) workarea: 2560x1060
2015-11-10 10:52:58,446     DISPLAY1 1920x1080 at 640x0 (621x341 mm - DPI: 78x80) workarea: 1920x1060
2015-11-10 10:52:58,446     DISPLAY2 640x360 (597x336 mm - DPI: 27x27) workarea: 640x340
2015-11-10 10:52:58,634 Xpra X11 server version 0.16.0-r11152
2015-11-10 10:52:58,634  running on Linux Fedora 21 Twenty One
2015-11-10 10:52:58,664 Server does not support rounding, disabling scaling
2015-11-10 10:52:58,664 sending updated screen size to server: 5120x2160 with 1 screens
2015-11-10 10:52:58,680   Default (1354x571 mm - DPI: 96x96) workarea: 5120x2120
2015-11-10 10:52:58,680     DISPLAY1 3840x2160 at 1280x0 (621x341 mm - DPI: 157x160) workarea: 3840x2120
2015-11-10 10:52:58,680     DISPLAY2 1280x720 (597x336 mm - DPI: 54x54) workarea: 1280x680
2015-11-10 10:52:58,680 Server's virtual screen is too small
2015-11-10 10:52:58,680  server: 2560x1080 vs client: 5120x2160
2015-11-10 10:52:58,680  you may see strange behavior,
2015-11-10 10:52:58,680  please see http://xpra.org/trac/wiki/Xdummy#Configuration

... when I noticed that the server side version wasn't the latest, I found I had to yum localinstall your latest rpms (some issue with the build in the repo?).

Even after localinstall - the Session Info is still showing the server as being r11152, and still giving me that warning.

However... if I scale up and down enough (3 to 5 times, or more, in a minute) and then immediately try to disconnect the client (control-C) - the client locks up, requiring use of the task manager to disconnect (the tray icon with the disconnect option becomes as non-responsive as all of the session applications).

Client side, I just see 2015-11-10 13:45:34,364 received console event CTRL_C, but the application doesn't exit.

Server side I see a whole lot of error messages suggesting that there are some back damage acks that are still being processed, causing the hang up:

2015-11-10 13:45:12,671 sent updated screen size to 1 client: 3200x1080 (max 8192x4096)
2015-11-10 13:45:53,363 delayed_region_timeout: region is 15008ms old, bad connection?
2015-11-10 13:46:08,384 delayed_region_timeout: region is 15014ms old, bad connection?
2015-11-10 13:46:23,423 delayed_region_timeout: region is 15034ms old, bad connection?
2015-11-10 13:46:38,515 delayed_region_timeout: region is 15087ms old, bad connection?
2015-11-10 13:46:38,544 Error: expiring missing damage acks: [6784, 6785, 6786, 6787, 6788, 6789, 6790, 6791, 6792, 6793, 6773, 6774, 6775, 6776, 6777, 6778, 6779, 6780, 6781, 6782, 6783]
2015-11-10 13:46:39,539 Error: expiring missing damage acks: [6794, 6795, 6796, 6797, 6798, 6799, 6800, 6801, 6802]
2015-11-10 13:46:53,702 delayed_region_timeout: region is 15182ms old, bad connection?
2015-11-10 13:47:15,432 delayed_region_timeout: region is 15344ms old, bad connection?
2015-11-10 13:47:30,793 delayed_region_timeout: region is 15356ms old, bad connection?
2015-11-10 13:47:46,045 delayed_region_timeout: region is 15250ms old, bad connection?
2015-11-10 13:48:01,278 delayed_region_timeout: region is 15228ms old, bad connection?
2015-11-10 13:48:01,308 Error: expiring missing damage acks: [6803, 6804, 6805, 6806, 6807, 6808, 6809, 6810, 6811, 6812, 6813, 6814, 6815, 6816, 6817, 6818]
2015-11-10 13:48:16,521 delayed_region_timeout: region is 15241ms old, bad connection?
2015-11-10 13:48:16,536 Error: expiring missing damage acks: [6819]
2015-11-10 13:48:38,313 delayed_region_timeout: region is 15362ms old, bad connection?
...

Wed, 11 Nov 2015 01:18:04 GMT - alas:

... Almost forgot comment:32.

Testing with 0.16.0 r11176 osx client (and with same version windows client) against fedora 21 0.16.0 r11178.

I set XPRA_TRAY_SCALING_OPTIONS=0.4,0.5 - but it doesn't seem to be behaving as I would've expected... not sure if it's the behavior that's wrong though, or my expectations.

When I scale "up" (shift-alt-+), with the above environment variable, the dpi scales to 32 in both cases - which is a scaling of 1/3 (assuming mere math applies to dpi). Scaling again, in both cases, scales to a dpi of 21 - which is again a 1/3 factor, adjusted for rounding.

I was expecting (perhaps foolishly?) that the 0.4 and 0.5 values of the variable would be the factor by which the scaling would be applied.

Just as a second check, the osx client default (48 dpi) has workarea of 1707x1660, which scales to 1138x1107, which seems to round up slightly above a factor of .666. Likewise, the windows client with the default (48 dpi) workarea of 2560x1080 scales to 1707x720, a factor of slightly more than .666.

Running again without the environment variable, though, and the (shift-alt-+) scaling seems to scale by the same factors as with the environment variable.

Did I misinterpret what that variable is supposed to do?


Wed, 11 Nov 2015 04:43:46 GMT - Antoine Martin:

not sure if it's the behavior that's wrong though, or my expectations.


This seemed like a reasonable expectation so r11180 does this and also ensures that we show the new scaling value as selected in the systray menu.

Notes:

See also: wiki/DPI


Wed, 18 Nov 2015 16:27:04 GMT - Antoine Martin:

There was a bug in the pixmap backing (opengl=no), which only manifested itself with scaling values lower than 1.0: #1036.


Tue, 12 Jan 2016 01:30:45 GMT - alas: owner changed

Interestingly, testing for #919 with 0.16.1 r11604 osx client against 0.16.1 fedora 23 server (r11649 I think)... I was re-scaling a display with the local System Preferences, and came across a traceback.

Scaling locally from 2560x1440 to 2048x1152 (with a default desktop-scaling value of 1.5), I had no problems... but when I scaled locally from 2048x1152 to 1600x900 I got the following traceback (further local scaling didn't reproduce... neither with the laptop display nor the second display, neither scaling up nor down).

Server-side, all I got was 2016-01-11 12:34:42,736 Warning: client decoding error: delta region bucket 0 references pixmap data we do not have!.

Client-side:

2016-01-11 12:34:13,761 sending updated screen size to server: 1707x1468 with 1 screens
2016-01-11 12:34:13,762   schadenfreude.local (903x776 mm - DPI: 48x48)
2016-01-11 12:34:13,762     monitor 1 1120x700 at 587x768 (592x370 mm - DPI: 48x48)
2016-01-11 12:34:13,762     monitor 2 1365x768 (722x406 mm - DPI: 48x48)
2016-01-11 12:34:13,762 screen size change: will reinit the windows
2016-01-11 12:34:30,097 sending updated screen size to server: 1707x1300 with 1 screens
2016-01-11 12:34:30,098   schadenfreude.local (903x687 mm - DPI: 48x48)
2016-01-11 12:34:30,098     monitor 1 1120x700 at 587x600 (592x370 mm - DPI: 48x48)
2016-01-11 12:34:30,098     monitor 2 1067x600 (564x317 mm - DPI: 48x48)
2016-01-11 12:34:30,098 screen size change: will reinit the windows
2016-01-11 12:34:30,285 draw error
Traceback (most recent call last):
  File "/Users/Schadenfreude/Desktop/xpra-catalog/xpra-16-1-ant-11604/Xpra.app/Contents/Resources/lib/python/xpra/client/ui_client_base.py", line 2587, in _do_draw
    window.draw_region(x, y, width, height, coding, data, rowstride, packet_sequence, options, [record_decode_time])
  File "/Users/Schadenfreude/Desktop/xpra-catalog/xpra-16-1-ant-11604/Xpra.app/Contents/Resources/lib/python/xpra/client/client_window_base.py", line 538, in draw_region
    backing.draw_region(x, y, width, height, coding, img_data, rowstride, options, callbacks)
  File "/Users/Schadenfreude/Desktop/xpra-catalog/xpra-16-1-ant-11604/Xpra.app/Contents/Resources/lib/python/xpra/client/window_backing_base.py", line 521, in draw_region
    self.paint_rgb32(img_data, x, y, width, height, rowstride, options, callbacks)
  File "/Users/Schadenfreude/Desktop/xpra-catalog/xpra-16-1-ant-11604/Xpra.app/Contents/Resources/lib/python/xpra/client/window_backing_base.py", line 301, in paint_rgb32
    rgb32_data = self.process_delta(raw_data, width, height, rowstride, options)
  File "/Users/Schadenfreude/Desktop/xpra-catalog/xpra-16-1-ant-11604/Xpra.app/Contents/Resources/lib/python/xpra/client/window_backing_base.py", line 180, in process_delta
    raise Exception("delta region bucket %s references pixmap data we do not have!" % bucket)
Exception: delta region bucket 0 references pixmap data we do not have!
2016-01-11 12:34:30,291 error processing draw packet
Traceback (most recent call last):
  File "/Users/Schadenfreude/Desktop/xpra-catalog/xpra-16-1-ant-11604/Xpra.app/Contents/Resources/lib/python/xpra/client/ui_client_base.py", line 2527, in _draw_thread_loop
    self._do_draw(packet)
  File "/Users/Schadenfreude/Desktop/xpra-catalog/xpra-16-1-ant-11604/Xpra.app/Contents/Resources/lib/python/xpra/client/ui_client_base.py", line 2587, in _do_draw
    window.draw_region(x, y, width, height, coding, data, rowstride, packet_sequence, options, [record_decode_time])
  File "/Users/Schadenfreude/Desktop/xpra-catalog/xpra-16-1-ant-11604/Xpra.app/Contents/Resources/lib/python/xpra/client/client_window_base.py", line 538, in draw_region
    backing.draw_region(x, y, width, height, coding, img_data, rowstride, options, callbacks)
  File "/Users/Schadenfreude/Desktop/xpra-catalog/xpra-16-1-ant-11604/Xpra.app/Contents/Resources/lib/python/xpra/client/window_backing_base.py", line 521, in draw_region
    self.paint_rgb32(img_data, x, y, width, height, rowstride, options, callbacks)
  File "/Users/Schadenfreude/Desktop/xpra-catalog/xpra-16-1-ant-11604/Xpra.app/Contents/Resources/lib/python/xpra/client/window_backing_base.py", line 301, in paint_rgb32
    rgb32_data = self.process_delta(raw_data, width, height, rowstride, options)
  File "/Users/Schadenfreude/Desktop/xpra-catalog/xpra-16-1-ant-11604/Xpra.app/Contents/Resources/lib/python/xpra/client/window_backing_base.py", line 180, in process_delta
    raise Exception("delta region bucket %s references pixmap data we do not have!" % bucket)
Exception: delta region bucket 0 references pixmap data we do not have!

Tue, 12 Jan 2016 01:44:22 GMT - Antoine Martin: owner changed

This Exception: delta region bucket 0 references pixmap data we do not have! can occur when re-initialize the windows because of scaling. I haven't found a workaround yet, but we shouldn't worry too much about it: the picture will just get re-sent and the delta will get reset.

Can we close this?


Tue, 12 Jan 2016 02:12:27 GMT - alas:

One last issue (maybe-issue) I can see.

Connecting with --desktop-scaling=1.5,1, aside from having funny-looking windows, if I scale down past the point where the x-scaling drops below 100%, then the "relative" scaling values seem to be lost... and not restored if I then scale back up past the 100% x-value.

2016-01-11 18:00:42,909 setting scaling to 150% x 100%:
2016-01-11 18:00:42,909 sending updated screen size to server: 1707x2490 with 1 screens
2016-01-11 18:00:42,910   schadenfreude.local (903x878 mm - DPI: 48x72)
2016-01-11 18:00:42,910     monitor 1 1120x1050 at 587x1440 (592x370 mm - DPI: 48x72)
2016-01-11 18:00:42,910     monitor 2 1707x1440 (903x508 mm - DPI: 48x72)
2016-01-11 18:00:48,164 setting scaling to 125% x 83%:
2016-01-11 18:00:48,165 sending updated screen size to server: 2048x2988 with 1 screens
2016-01-11 18:00:48,165   schadenfreude.local (903x878 mm - DPI: 57x86)
2016-01-11 18:00:48,165     monitor 1 1344x1260 at 704x1728 (592x370 mm - DPI: 57x86)
2016-01-11 18:00:48,165     monitor 2 2048x1728 (903x508 mm - DPI: 57x86)
2016-01-11 18:00:53,869 setting scaling to 100% x 67%:
2016-01-11 18:00:53,869 sending updated screen size to server: 2560x3735 with 1 screens
2016-01-11 18:00:53,869   schadenfreude.local (903x878 mm - DPI: 72x108)
2016-01-11 18:00:53,870     monitor 1 1680x1575 at 880x2160 (592x370 mm - DPI: 72x108)
2016-01-11 18:00:53,870     monitor 2 2560x2160 (903x508 mm - DPI: 72x108)
2016-01-11 18:00:57,549 Warning: cannot scale by 0.666 x 0.444 or lower
2016-01-11 18:00:57,549  the scaled client screen 2560 x 2490 -> 3843 x 5608
2016-01-11 18:00:57,549  would overflow the server's screen: 8192 x 4096
2016-01-11 18:00:57,549  using 0.60791015625 x 0.60791015625 -> 4211 x 4096
2016-01-11 18:00:57,550 setting scaling to 61%:
2016-01-11 18:00:57,550 sending updated screen size to server: 4211x4096 with 1 screens
2016-01-11 18:00:57,550   schadenfreude.local (903x878 mm - DPI: 118x118)
2016-01-11 18:00:57,550     monitor 1 2764x1727 at 1448x2369 (592x370 mm - DPI: 118x118)
2016-01-11 18:00:57,551     monitor 2 4211x2369 (903x508 mm - DPI: 118x118)
2016-01-11 18:01:06,717 setting scaling to 67%:
2016-01-11 18:01:06,717 sending updated screen size to server: 3844x3739 with 1 screens
2016-01-11 18:01:06,717   schadenfreude.local (903x878 mm - DPI: 108x108)
2016-01-11 18:01:06,718     monitor 1 2523x1577 at 1321x2162 (592x370 mm - DPI: 108x108)
2016-01-11 18:01:06,718     monitor 2 3844x2162 (903x508 mm - DPI: 108x108)
2016-01-11 18:01:12,317 setting scaling to 100%:
2016-01-11 18:01:12,317 sending updated screen size to server: 2560x2490 with 1 screens
2016-01-11 18:01:12,317   schadenfreude.local (903x878 mm - DPI: 72x72)
2016-01-11 18:01:12,317     monitor 1 1680x1050 at 880x1440 (592x370 mm - DPI: 72x72)
2016-01-11 18:01:12,317     monitor 2 2560x1440 (903x508 mm - DPI: 72x72)
2016-01-11 18:01:14,037 setting scaling to 125%:
2016-01-11 18:01:14,038 sending updated screen size to server: 2048x1992 with 1 screens
2016-01-11 18:01:14,038   schadenfreude.local (903x878 mm - DPI: 57x57)
2016-01-11 18:01:14,038     monitor 1 1344x840 at 704x1152 (592x370 mm - DPI: 57x57)
2016-01-11 18:01:14,038     monitor 2 2048x1152 (903x508 mm - DPI: 57x57)
2016-01-11 18:01:17,853 setting scaling to 150%:
2016-01-11 18:01:17,853 sending updated screen size to server: 1707x1660 with 1 screens
2016-01-11 18:01:17,853   schadenfreude.local (903x878 mm - DPI: 48x48)
2016-01-11 18:01:17,853     monitor 1 1120x700 at 587x960 (592x370 mm - DPI: 48x48)
2016-01-11 18:01:17,853     monitor 2 1707x960 (903x508 mm - DPI: 48x48)

Not sure i'd call this a bug, but my initial expectation would be that the relative-scaling values would be "re-asserted" as the x-value scales back up over 100% (I suppose this would require saving those initial values somewhere to check against).

Oddly, trying with the reverse (--desktop-scaling=1,1.5, the scaling value "relativity" was preserved longer:

2016-01-11 18:07:38,607 setting scaling to 100% x 150%:
2016-01-11 18:07:38,607 sending updated screen size to server: 2560x1660 with 1 screens
2016-01-11 18:07:38,607   schadenfreude.local (903x878 mm - DPI: 72x48)
2016-01-11 18:07:38,608     monitor 1 1680x700 at 880x960 (592x370 mm - DPI: 72x48)
2016-01-11 18:07:38,608     monitor 2 2560x960 (903x508 mm - DPI: 72x48)
2016-01-11 18:07:39,791 setting scaling to 83% x 125%:
2016-01-11 18:07:39,791 sending updated screen size to server: 3072x1992 with 1 screens
2016-01-11 18:07:39,792   schadenfreude.local (903x878 mm - DPI: 86x57)
2016-01-11 18:07:39,792     monitor 1 2016x840 at 1056x1152 (592x370 mm - DPI: 86x57)
2016-01-11 18:07:39,792     monitor 2 3072x1152 (903x508 mm - DPI: 86x57)
2016-01-11 18:07:41,286 setting scaling to 67% x 100%:
2016-01-11 18:07:41,287 sending updated screen size to server: 3840x2490 with 1 screens
2016-01-11 18:07:41,287   schadenfreude.local (903x878 mm - DPI: 108x72)
2016-01-11 18:07:41,287     monitor 1 2520x1050 at 1320x1440 (592x370 mm - DPI: 108x72)
2016-01-11 18:07:41,287     monitor 2 3840x1440 (903x508 mm - DPI: 108x72)
2016-01-11 18:07:42,382 setting scaling to 44% x 67%:
2016-01-11 18:07:42,383 sending updated screen size to server: 5766x3739 with 1 screens
2016-01-11 18:07:42,383   schadenfreude.local (903x878 mm - DPI: 162x108)
2016-01-11 18:07:42,383     monitor 1 3784x1577 at 1982x2162 (592x370 mm - DPI: 162x108)
2016-01-11 18:07:42,383     monitor 2 5766x2162 (903x508 mm - DPI: 162x108)
2016-01-11 18:07:44,422 Warning: cannot scale by 0.333333333333 x 0.5 or lower
2016-01-11 18:07:44,422  the scaled client screen 2560 x 2490 -> 7679 x 4980
2016-01-11 18:07:44,423  would overflow the server's screen: 8192 x 4096
2016-01-11 18:07:44,423  using 0.60791015625 x 0.60791015625 -> 4211 x 4096
2016-01-11 18:07:44,423 setting scaling to 61%:
2016-01-11 18:07:44,423 sending updated screen size to server: 4211x4096 with 1 screens
2016-01-11 18:07:44,423   schadenfreude.local (903x878 mm - DPI: 118x118)
2016-01-11 18:07:44,423     monitor 1 2764x1727 at 1448x2369 (592x370 mm - DPI: 118x118)
2016-01-11 18:07:44,423     monitor 2 4211x2369 (903x508 mm - DPI: 118x118)
2016-01-11 18:07:46,415 setting scaling to 67%:
2016-01-11 18:07:46,415 sending updated screen size to server: 3844x3739 with 1 screens
2016-01-11 18:07:46,415   schadenfreude.local (903x878 mm - DPI: 108x108)
2016-01-11 18:07:46,415     monitor 1 2523x1577 at 1321x2162 (592x370 mm - DPI: 108x108)
2016-01-11 18:07:46,416     monitor 2 3844x2162 (903x508 mm - DPI: 108x108)
2016-01-11 18:07:47,479 setting scaling to 100%:
2016-01-11 18:07:47,479 sending updated screen size to server: 2560x2490 with 1 screens
2016-01-11 18:07:47,479   schadenfreude.local (903x878 mm - DPI: 72x72)
2016-01-11 18:07:47,479     monitor 1 1680x1050 at 880x1440 (592x370 mm - DPI: 72x72)
2016-01-11 18:07:47,480     monitor 2 2560x1440 (903x508 mm - DPI: 72x72)
2016-01-11 18:07:48,727 setting scaling to 125%:
2016-01-11 18:07:48,727 sending updated screen size to server: 2048x1992 with 1 screens
2016-01-11 18:07:48,727   schadenfreude.local (903x878 mm - DPI: 57x57)
2016-01-11 18:07:48,728     monitor 1 1344x840 at 704x1152 (592x370 mm - DPI: 57x57)
2016-01-11 18:07:48,728     monitor 2 2048x1152 (903x508 mm - DPI: 57x57)

Or, if that's just too ridiculous a set of user behaviors to support, then sure, let's close this.


One last detail, after trying these strange scaling maneuvers, when I disconnect the client I get some client-side warnings that might be of interest (unlikely, but I'll post anyway).

got signal SIGINT, exiting
2016-01-11 18:09:54,188 sound output stopping
/Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-17-11640/Xpra.app/Contents/Resources/lib/python/xpra/client/gl/gl_window_backing_base.py:435: Warning: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
  self.glconfig = None
/Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-17-11640/Xpra.app/Contents/Resources/lib/python/xpra/client/gtk_base/gtk_client_window_base.py:995: Warning: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
  gtk.Window.destroy(self)
/Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-17-11640/Xpra.app/Contents/Resources/lib/python/xpra/gtk_common/gtk_util.py:365: Warning: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
  gtk.main()

Tue, 12 Jan 2016 03:35:27 GMT - Antoine Martin:


I'll backport the first two and if that works for you then I think we can finally close this ticket. If you can reproduce the third one then please file a new ticket and link it from here and #980.


Tue, 12 Jan 2016 22:51:48 GMT - alas:

Hmm, testing with osx client 0.17.0 r11653 against fedora 23 0.17.0 r11669, when I try to mix scalings (starting client with ./xpra attach tcp:10.0.32.134:1203 --opengl=on --desktop-scaling=1.8,110%), the server doesn't seem to recognize the % value (2016-01-12 12:58:15,342 upscaled by 180% x 100%, virtual screen size: 1422x2490). (Perhaps leading to client crash posted in #1087.)

Connecting a 0.17.0 r11653 windows client with mis-matching "units" had a similar result (--desktop-scaling=1.2,170% led to upscaled by 120% x 100% ... and while scaling up and down worked as expected, using control-C to disconnect triggered an odd traceback (#1088).

Connecting with --desktop-scaling=120%,170% ... resulted in no scaling at all (well, 100% I suppose). Repeating with OSX client, but with desktop-scaling=180%,110%, the display size output client side also indicates no scaling, but using that flag when shifting the session from that earlier indicated windows session to the osx, the xterm start-childs were incredibly oddly "squashed" — that is to say, the frames were essentially two columns high, while an expected width. (Probably just an odd coincidence, but perhaps helpful.)

Likewise, connecting with OSX client with ---desktop-scaling=180% seems to display at 100%.

Connecting with desktop-scaling=1.2,1.7 though, works as expected, and the "relative" scaling is respected within reasonable limits and re-asserts as scaling shifts back into "middling" ranges.

Hehe, do we really need clients to be able to use percentages? (Ok, ok... we'll get that, then finally close this ticket.)


Wed, 13 Jan 2016 05:39:12 GMT - Antoine Martin:

Good catch, the percentage parsing is fixed in r11671 (will backport). It was only working with multiples of 100... or python3!


Wed, 13 Jan 2016 23:05:23 GMT - alas: owner changed

Ok — tested with 0.17.0 r11687 osx and windows clients against 0.17.0 r11692 fedora 23 server.

Percentages work, decimals work, "relative" scaling works & is maintained as scaling is shortcut-adjusted up or down... mixing percentages and decimals works.

Then I remembered to try the shift-alt-asterisk shortcut with scaling at something odd (129%x150%?; scaled down from initial 143%x166%) ... and noticed that it reset to a simple 100% scaling (rather than the "initial" setting)... and from there it scaled up as expected (125%, 150%, etc.).

I'm not sure if the asterisk short cut should go back to 100% or to the initial setting. I could see the virtues of leaving it as is for users to "turn off" scaling... or have it jump back to the initialized default. The "turn off" option has the distinct appeal of allowing us to close this ticket.

I'll hand this back to you yet again to decide.


Thu, 21 Jan 2016 06:23:00 GMT - Antoine Martin: owner changed

@afarr: if that works for you then please close. (I'm not going to backport these)


Fri, 22 Jan 2016 01:02:43 GMT - Antoine Martin:

r11718 fixes the scalingoff shortcut (missed commit on window class), beta win32 build uploaded.


Fri, 22 Jan 2016 01:37:16 GMT - alas: status changed; resolution set

Testing with win32 0.17.0 r11718 client against a 0.17.0 r11705 fedora 23 server... all those last fixes are working as expected.

Since I can't think of any other nitpicks, or find anything else - I'll close.


Thu, 28 Jan 2016 06:16:15 GMT - Antoine Martin:

Follow up in #1101


Sat, 23 Jan 2021 05:11:23 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/976