xpra icon
Bug tracker and wiki

Opened 22 months ago

Closed 17 months ago

Last modified 17 months ago

#976 closed enhancement (fixed)

scale the local display

Reported by: Antoine Martin Owned by: alas
Priority: critical Milestone: 0.16
Component: client Version: 0.15.x
Keywords: Cc:

Description

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:

Attachments (7)

client-scaling.patch (41.0 KB) - added by Antoine Martin 22 months ago.
work in progress - rendering part not done (big)
client-scaling-v2.patch (43.5 KB) - added by Antoine Martin 22 months ago.
mostly working patch - opengl done
client-scaling-v6.patch (53.2 KB) - added by Antoine Martin 22 months ago.
working with all backends: cairo, pixmap and opengl!
976-comment11-cursor-log.txt (16.6 KB) - added by Antoine Martin 21 months ago.
moving the cursor log to an attachment
ticket976-comment16_lots-of-scaling-up-and-down-made-server-non-responsive_info.txt (142.0 KB) - added by alas 21 months ago.
initial scaling induced crash server info - comment 16
ticket976-comment16_scaling-past-5x5dpi-crash_info.txt (68.0 KB) - added by alas 21 months ago.
scaling up, up, and away - crashes client ... comment16
ticket976_2x-scaling-default-not-displaying-anywhere-near-local-display-dpi.PNG (1.8 MB) - added by alas 21 months ago.
desktop-scaling=auto 2x scaled on 4k window on left, local 157x160 DPI browser on right - don't match

Change History (58)

Changed 22 months ago by Antoine Martin

Attachment: client-scaling.patch added

work in progress - rendering part not done (big)

comment:1 Changed 22 months ago by Antoine Martin

Status: newassigned

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

  • session info updates: show scaling somewhere, adjust values
  • expose to server? (so we can debug via xpra info)
  • get_frame_extents / get_window_frame_sizes / get_window_frame_size - not done
  • cursors (not scaled) - not sure if we should..
  • downscaling client side is wasteful: the server should downscale instead, disallow values lower than 1.0?
  • pixmap and cairo backings not done: keep track of render size and scale as needed (using Pillow, gdk pixbuf and csc...)
  • resize support: could scale until the next screen update comes through
  • anti-aliasing tweaks?
  • tray menu entry to control?
  • magic keys bindings to upscale / downscale individual windows, control channel? (should probably affect all windows for a group leader?)

to verify:

  • get_client_window_classes could use backing size? the opengl limit is on the texture? (but we also render to a PBO?)
  • geometry hints handling
  • system trays: maybe those should not be scaled in size, just position?
  • spinners
  • toggling opengl on / off
  • alpha, shape, etc..
Last edited 22 months ago by Antoine Martin (previous) (diff)

Changed 22 months ago by Antoine Martin

Attachment: client-scaling-v2.patch added

mostly working patch - opengl done

Changed 22 months ago by Antoine Martin

Attachment: client-scaling-v6.patch added

working with all backends: cairo, pixmap and opengl!

comment:2 Changed 22 months ago by 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:

  • most items from comment:1
  • maybe support specifying the scaling as ratios, as we already do server side via parse_scaling_value (ie: support 3/2), and send this to the server instead of a float multiplied by 1000...
  • add command line switch: --client-scaling=off|auto|XVALUE,YVALUE, auto could enabled client side scaling if DPI is high? or if the desktop size is very big, or both?
  • maybe update #942: we now can have windows bigger than the max texture size by downscaling them... and maybe we should automatically downscale in this case? (and check for GL_MAX_VIEWPORT_DIMS instead - which should always be bigger than the texture size already?)
  • maybe implement #972 the easy way for now: don't deal with offsets, just scale the window to fullscreen size
  • spinners with opengl are probably using the wrong dimensions?
  • verify the DPI issues with win 8.1 and later: we really don't want the OS to upscale our window contents again if we've done it ourselves (scaling is often a lossy operation unless we're multiplying the size by a round number, so best to do it just once)
Last edited 22 months ago by Antoine Martin (previous) (diff)

comment:3 Changed 22 months ago by Antoine Martin

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

comment:4 Changed 22 months ago by Antoine Martin

  • r10591 renamed the "scaling" option to "video-scaling" to prevent confusion, still controls video scaling aggressiveness (this scaling happens server side, before the video encoding)
  • r10621 adds the "desktop-scaling" option, see below for examples
  • 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 (see wikipedia: Graphics display resolution for the definition of the acronyms)
  • r10624 ensures we don't select scaling values too low, which the server would not be able to handle - also enables scaling automatically if the server max-size is too small to handle our screen size (as long as scaling is enabled obviously)

Here are some usage examples:

  • double the size of all windows: desktop-scaling = 2
  • increase the size by 50%%: desktop-scaling = 1.5 or desktop-scaling = 3/2
  • disable all desktop scaling: desktop-scaling = off or desktop-scaling = 0
  • enable desktop scaling, but start with no scaling activated (the default): desktop-scaling = 1 or desktop-scaling = on
  • auto mode: desktop-scaling=auto

Still TODO:

  • man page updates
  • blurriness seen in partial repaints with cairo and pixmap backings (disable scaling with those, or use slow-full-window repaint?)
  • dpi and cursors?
  • test system trays?
  • limit downscaling more? (useful for testing, but a complete waste of bandwidth and CPU)
  • xshape fixes..

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

comment:5 Changed 22 months ago by Antoine Martin

Owner: changed from Antoine Martin to alas
Status: assignednew
  • man page updates in r10647
  • scaling cursors done in r10648
  • dpi should be ok as it is.. no better or worse I think, though the new virtual size does make it harder to figure out what the "real" dpi should be!
  • systray forwarding fixed in r10650
  • not going to limit downscaling: let people do stupid things, can also be useful to display a large desktop (ie: 4k or above) on a very small screen (ie: vga)
  • xshape: fixed in r10652 (not perfect - not sure we can make it much better, and not sure we care)
  • r10653 adds a keyboard shortcut to reset scaling to 1: Alt+Shift+KP_Multiply (aka "*" on numpad)
  • r10655 fixes repaints with non-opengl backends: we now repaint the whole window when scaling (see commit message for env var to tweak this)

@afarr: ready for testing:

  • the new command line switch, including "auto" mode which we may want to use as default in the future (and we can adjust the thresholds if needed)
  • key shortcuts to toggle at runtime: Alt+Shift+Plus and Alt+Shift+Minus, and ensuring we don't overflow the max server screen size
  • system tray forwarding (ie: vlc has one)
  • dpi - not sure how to test?
  • cursors should scale up / down too
  • xshape (ie: xeyes uses that)

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

  • add a tray menu to easily toggle scaling?
  • add server-side downscaling? (would save lots of bandwidth if the client is not going to use all those pixels)
Last edited 22 months ago by Antoine Martin (previous) (diff)

comment:6 Changed 22 months ago by maxmylyn

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

  • Tested --desktop-scaling=auto (unable to trigger due to resolution being at 1080p), everything works the same as before, even after a couple hours of normal usage (surfing Trac comments in Firefox, emails in Thunderbird).
  • Key shortcuts work(as in manually scale) as expected.
  • System tray forwarding does not work properly
    • The icon stays the same, but when scaling down or up, the right click menu on VLC no longer works
  • 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
  • Not sure how to test xshape
Last edited 22 months ago by maxmylyn (previous) (diff)

comment:7 Changed 22 months ago by Antoine Martin

Owner: changed from alas to maxmylyn

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:

  • there's a limit to how big we can make the cursor (128x128 on my dev box) - and the limit calculations were wrong
  • on many platforms (X11 for a start), the cursor won't actually change until you move the mouse by at least one pixel
  • some platforms (like win32) use fixed cursor sizes (we could add code to paste the cursor into a transparent frame to emulate smaller sizes - meh, the fixed size is quite small already)
  • for testing, this little test script is useful: ./tests/xpra/test_apps/test_custom_cursor.py (each window uses a different type of cursor - see window title)
  • if you still have problems, please include -d cursor debug output.


Not sure how to test xshape


xeyes

comment:8 Changed 21 months ago by Antoine Martin

Priority: majorcritical

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

comment:9 Changed 21 months ago by maxmylyn

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:

  • Cursor no longer scales for me (up or down)
    • thanks for the python file - that helps

-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>

comment:10 Changed 21 months ago by 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.

comment:11 Changed 21 months ago by maxmylyn

Owner: changed from maxmylyn to Antoine Martin

Upped to r10783:

  • Fedora client now scaled the cursor properly.
  • Windows client does not scale properly (not sure if it's expected or not)
  • Scaling down then attempting to use VLC's tray icon in Windows causes the right click to be sent to Google-Chrome (?) - and then Chrome's right click menu is activated
    • Not sure what logs you'd like, let me know and I'll provide
    • Resetting scale causes it to work normally
  • Scaling up/down in Fedora 19 causes VLC's tray icon to stop working altogether

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

Last edited 21 months ago by Antoine Martin (previous) (diff)

Changed 21 months ago by Antoine Martin

moving the cursor log to an attachment

comment:12 Changed 21 months ago by Antoine Martin

Status: newassigned

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:

  • if the cursor is meant to be smaller, we paste the cursor image onto the target size (leaving the edges transparent), so it looks the right size (so downscaling should sort of work)
  • we can't make the cursors bigger than the fixed cursor size, so we just scale them up (or down) to that maximum size... shows up as:
    scaling cursor from 48x48 to fixed OS size 32x32
    


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.

Last edited 21 months ago by Antoine Martin (previous) (diff)

comment:13 Changed 21 months ago by Antoine Martin

Owner: changed from Antoine Martin to maxmylyn
Status: assignednew

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)

Last edited 21 months ago by Antoine Martin (previous) (diff)

comment:14 Changed 21 months ago by maxmylyn

Owner: changed from maxmylyn to Antoine Martin

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

  • VLC tray works as expected in Windows
  • I have also seen mild visual corruption on the taskbar icon when scaling up and down
    • Tested Fedora and Windows clients, mild corruption only notable in Windows(you can see the quality change on Fedora, but that's all)

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

comment:15 Changed 21 months ago by Antoine Martin

Owner: changed from Antoine Martin to alas

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 DPI and the Desktop Scaling Factor), but as of r10832 we should now claim to be Process_System_DPI_Aware via 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 GetDpiForMonitor, 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.

comment:16 Changed 21 months ago by 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.

Last edited 21 months ago by Antoine Martin (previous) (diff)

Changed 21 months ago by alas

initial scaling induced crash server info - comment 16

Changed 21 months ago by alas

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

comment:17 Changed 21 months ago by alas

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

  • I run into the difficulty that my laptop has no numpad, so I end up using fn+option/alt+shift+_ when trying to input alt-shift-minus - without the numpad I can't input shift and minus at the same time. (Used gtk_view_keyboard.py to confirm server-side keystroke inputs.)
  • Likewise I have no access to the KP_Multiply key, only the asterisk key.
  • fn-option/alt-shift-plus to effect an alt-shift-plus (again, keystrokes confirmed with gtk_view_keyboard.py) also seems to have no effect.

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?

comment:18 Changed 21 months ago by 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.

Last edited 21 months ago by Antoine Martin (previous) (diff)

comment:19 Changed 21 months ago by 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.

comment:20 Changed 21 months ago by 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)

  • The --desktop-scaling=auto works as expected (with the 2x2).
  • Trying with --desktop-scaling=0.73, --desktop-scaling=1, desktop=-scaling=1.6, as well as --desktop-scaling=3/2 all work as expected.
  • The cursors on this windows 8.1 don't seem to be scaling, however. (I'll try to test some with the -d cursor mentioned above later.)

comment:21 Changed 21 months ago by 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.

Last edited 21 months ago by Antoine Martin (previous) (diff)

comment:22 Changed 21 months ago by 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.

Changed 21 months ago by alas

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

comment:23 Changed 21 months ago by 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.

comment:24 Changed 21 months ago by alas

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

  • shift+fn+option/alt+=/+ seems be working as expected now, with the shift part causing the gtk_view_keyboard tool to register the "=/+" to interpret as a "+".
  • shift-fn-option/alt--/_, however, still is failing to work - despite checking the key-shortcuts showing Meta+Shift+underscore:scaledown. As an experiment I added --key-shortcut=Meta+Shift+Underscore:scaledown, at which point it worked as expected... which was odd, since the gtk_view_keyboard tool does list it as "underscore"... even more confusing, though, is that when I tried it a second time adding --key-shortcut=Meta+Shift+Asterisk:scalereset it not only failed to work, but afterward I couldn't get the original underscore key shortcut to work again (???).
  • As a note - I did notice that the gtk_keyboard tool listed the exact same values whether I click the (left) control key or the "fn+option/alt" key-combo
    down   Alt_L   65513   64    1 0 ['2']
    up      Alt_L   65513   64    1 0 ['2', '1']
    

... 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

comment:25 Changed 21 months ago by 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:

  • we correctly change the DPI reported to the server (for 2x2, we halve it from 96x96 to 48x48)
  • we correctly adjust the screen dimensions reported to the server (for 2x2: from 5120x2160 to 2560x1080)
  • the client makes the window twice as big by upscaling it by 2x2 when displaying it

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:

  • can you reproduce this with a non-Intel graphics card? or even with opengl turned off? (bearing in mind that we care most about opengl=on)
  • the failure to get a colormap is a GTK issue which could be a symptom for something else, like running out of memory or some sort of graphics context resource. Maybe creating and closing windows many times could reproduce this problem? (when we scale up or down, we end up re-creating new windows - maybe there's a leak there)

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

  • forward the desired cursor size from the client to the server (ie: use the fixed cursor size on win32, or read the xsetting value on x11)
  • scale this value in the same way that we handle all screen coordinates
  • override the xsettings with this value on the server side
  • use a sensible default value so that applications which are started before a client connects will get a sensible cursor size (set to 24 for now)
Last edited 21 months ago by Antoine Martin (previous) (diff)

comment:26 Changed 21 months ago by 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:

  • shift-fn-option/alt-minus, when watched with -d keyboard, was producing Shift_L, Alt_L, and... emdash (don't you love it?).
  • shift-fn-option/alt-asterisk was producing Shift_L, Alt-L, and ... degree.

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.

comment:27 Changed 21 months ago by 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..)

Last edited 20 months ago by Antoine Martin (previous) (diff)

comment:28 Changed 20 months ago by 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
  • On the plus side though, the scaling up and scaling down shortcuts both worked and weren't able to crash the client.

comment:29 Changed 20 months ago by 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.

Last edited 20 months ago by Antoine Martin (previous) (diff)

comment:30 Changed 20 months ago by 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.

comment:31 Changed 20 months ago by 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.

comment:32 Changed 20 months ago by 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)

Last edited 20 months ago by Antoine Martin (previous) (diff)

comment:33 Changed 20 months ago by 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.

comment:34 Changed 20 months ago by 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.

comment:35 Changed 20 months ago by Antoine Martin

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

comment:36 Changed 20 months ago by Antoine Martin

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

comment:37 Changed 20 months ago by 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.

  • With our r11178 server build though, I wasn't able to repro the resizing loop.

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?
...

comment:38 Changed 20 months ago by 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.

  • The osx client's workarea is 2560x2490 with dpi of 72, so the default behavior is to scale by 1.5 to dpi of 48.
  • The windows client workarea is 5120x2160 with dpi of 96, so the default behavior is to scale by 2 to a dpi of 48 (a handy coincidence).

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?

  • The tray/application menu scaling options work as expected though, both osx and windows clients (and server).

comment:39 Changed 20 months ago by 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:

  • it is possible to specify different scaling values for X and Y coordinates using the command line, we then keep the same aspect ratio - only applicable to the keyboard shortcuts, using the tray menu will set both axis (we use the maximum value of X and Y as the "current" scaling value to choose the next step, up or down)
  • if the current scaling value is not one from the list of scaling value options (defaults or overriden via the env var), we choose the nearest match and show that one as selected

See also: wiki/DPI

Last edited 20 months ago by Antoine Martin (previous) (diff)

comment:40 Changed 20 months ago by Antoine Martin

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

Last edited 20 months ago by Antoine Martin (previous) (diff)

comment:41 Changed 18 months ago by alas

Owner: changed from alas to Antoine Martin

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!

comment:42 Changed 18 months ago by Antoine Martin

Owner: changed from Antoine Martin to alas

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?

comment:43 Changed 18 months ago by 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()

comment:44 Changed 18 months ago by Antoine Martin

  • 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. good catch, fixed in r11651 (it won't go as low as before, the code was just getting too ugly)
  • r11652 also allows us to specify the scaling as a percentage, since that's what we log, so this now works: --desktop-scaling=180%
  • when I disconnect the client I get some client-side warnings that might be of interest.. - very much so! This looks like a real bug where we destroy the same window more than once, r11653 should replace those GTK warnings with one of our own which should say Warning: window destroy called twice'' - this one worries me a bit, as the window re-init code is also used in other places (ie: #980), and should always be called from the UI thread

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.

Last edited 18 months ago by Antoine Martin (previous) (diff)

comment:45 Changed 18 months ago by 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.)

comment:46 Changed 18 months ago by Antoine Martin

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

comment:47 Changed 18 months ago by alas

Owner: changed from alas to Antoine Martin

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.

comment:48 Changed 17 months ago by Antoine Martin

Owner: changed from Antoine Martin to alas
  • r11703 will restore the initial scaling rather than 100%,100%
  • r11704 adds a shortcut for turning scaling off (100%, 100%): Meta+Shift+question

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

comment:49 Changed 17 months ago by Antoine Martin

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

comment:50 Changed 17 months ago by alas

Resolution: fixed
Status: newclosed

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.

comment:51 Changed 17 months ago by Antoine Martin

Follow up in #1101

Note: See TracTickets for help on using tickets.