Xpra: Ticket #2500: Text scaling regression in 4.0 macOS client

When attaching to a remote Xpra session, 3.0.2 shows text consistent with client side DPI, whereas 4.0.x shows text that is incredibly small. This is reproduced on both Ubuntu 18.04/Fedora 31 running both the latest beta and 3.0.2 xpra servers.



Fri, 29 Nov 2019 18:03:22 GMT - mjlbach: attachment set


Fri, 29 Nov 2019 18:05:25 GMT - mjlbach: attachment set

4.0.x


Sat, 30 Nov 2019 01:40:29 GMT - Antoine Martin: owner changed

Looks like an exact duplicate of #2480.

Please post:


Sat, 30 Nov 2019 01:46:57 GMT - mjlbach: attachment set


Sat, 30 Nov 2019 01:47:07 GMT - mjlbach: attachment set


Sat, 30 Nov 2019 01:47:16 GMT - mjlbach: attachment set


Sat, 30 Nov 2019 01:47:42 GMT - mjlbach:

Updated


Sat, 30 Nov 2019 01:51:46 GMT - Antoine Martin:

From your log:

Warning: invalid screen size 5719x6349mm
 using 339x212 mm

Maybe there's somewhere else we need to workaround the bogus values we get from GTK.

Can you please add the output of xpra info from the server?


Sat, 30 Nov 2019 02:07:22 GMT - mjlbach: attachment set


Sat, 30 Nov 2019 15:46:17 GMT - Antoine Martin:

First, r24470 was incomplete, r24535 fixes that so that we will actually use the monitor DPI when the screen DPI reported is clearly invalid. I've uploaded new beta builds for most platforms.

Sorry for bugging you again, but there are still things I can't figure out from the information you provided:

Running the client with -d display,screen,scaling should tell us.

Can you run the server with -d display,screen,scaling and post the server log?


Sat, 30 Nov 2019 17:06:13 GMT - mjlbach:

Updated to the latest beta on server/client. Here are the logs:


Sat, 30 Nov 2019 17:06:29 GMT - mjlbach: attachment set


Sat, 30 Nov 2019 17:06:42 GMT - mjlbach: attachment set


Sun, 01 Dec 2019 06:08:46 GMT - Antoine Martin:

Thanks for the logs.

upscaled to 200%

This is caused by #2438: get_monitor_scale_factor(0)=2. This must be a HIDPI display because GTK is telling us that there is a scale factor of 2. What is the actual resolution of your display? Is it really 1280x800? or maybe 2560x1600?

r24535 works and helps us find the correct value for the physical screen dimensions:

Warning: invalid screen size 5719x6349mm
 using 286x179 mm

Which is the monitor size:

  mjlbach-macbook-pro-2.local (286x179 mm - DPI: 113x113) workarea: 1280x709 at 0x23

Did you specify the --dpi=144 switch anywhere? Maybe in your local config? You can verify with:

$ xpra showconfig | grep dpi

Because this log output seems to imply that you did: dpi: (-1, -1) -> (36, 36). The value 36 makes more sense now, it was caused by a bug: that would be 144 upscaled by 200% (the value was wrongly divided by 200% twice, one for each axis - that's fixed in r24545).

Another important point worth mentioning is that many applications will only honour the DPI value when they start, changes in DPI settings will not be adjusted at runtime. So it is best to launch the applications used for testing after connecting from the client.

Not much to see on the server side:

I have uploaded a new macos beta build with r24545: https://xpra.org/beta/MacOS. This should help honour whatever DPI is set on the command line when desktop-scaling=auto kicks in, as it does on hidpi displays. Things you can try:

I have verified that the --dpi switch does do something by launching gedit on the server after connecting and the window title and menus do adapt to DPI settings. I will take another look at this for #1933 and #2410 eventually.


Sun, 01 Dec 2019 06:14:10 GMT - mjlbach:

The display resolution is 2560×1600 (2014 MBP retina 13"), I'm running at native resolution. I didn't specify any flags (just xpra attach ssh/host/1).

$ xpra showconfig | grep dpi
$ dpi                            = 0

I also started the program (firefox) only after starting the server and attaching to the display from the client. I'll give the new beta a try along with the suggested additional dpi/desktop scaling flags and report back!


Sun, 01 Dec 2019 06:32:24 GMT - mjlbach:

Update:

The text-size problem now appears only if the application is started after client attaches. If the application is started before attaching, the text-size is correct. In either case, the client-side scaling is still initially 200%.

Starting with --dpi=144 doubles the font size, but also results in scaling initially being set to 200%.

Setting --desktop-scaling=no seems to fix the problem regardless if I attach to a running application session, or start the application after attaching. The scaling is (unsurprisingly) none.

Setting both desktop scaling and dpi seems to make the scaling and font size consistent regardless of the order in which I start the application/attach.


Tue, 03 Mar 2020 12:47:49 GMT - Antoine Martin:

This should be fixed in r25481: undoing r24125 should prevent the double scaling you were seeing.

There's a new beta 4.0 build here: https://xpra.org/beta/MacOS/. @mjlbach: does that work OK for you?


Tue, 03 Mar 2020 15:54:36 GMT - mjlbach: status changed; resolution set

Seems like it is fixed on the latest beta! Thank you


Sun, 15 Mar 2020 07:22:21 GMT - Antoine Martin:

r24545 was incorrect and has been reverted in r25645.


Sat, 23 Jan 2021 05:52:59 GMT - migration script:

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