Text scaling regression in 4.0 macOS client

[totaam]

Issue migrated from trac ticket # 2500

component: client | priority: major | resolution: fixed

2019-11-29 18:03:02: mjlbach created the issue

---

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.

[totaam]

2019-11-29 18:03:22: mjlbach uploaded file Screen Shot 2019-11-29 at 9.50.22 AM.png (1056.2 KiB)

[totaam]

2019-11-29 18:05:25: mjlbach uploaded file Screen Shot 2019-11-29 at 8.31.26 AM.png (1126.3 KiB)

4.0.x

[totaam]

2019-11-30 01:40:29: antoine changed owner from antoine to mjlbach

[totaam]

2019-11-30 01:40:29: antoine commented

---

Looks like an exact duplicate of #2480.

Please post:

• the client output so we can see what DPI is detected
• the questions from Command key is stuck on Mac OS and Wrong DPI #2480#comment:1

[totaam]

2019-11-30 01:46:57: mjlbach uploaded file client_log.txt (2.9 KiB)

[totaam]

2019-11-30 01:47:07: mjlbach uploaded file gtk_info.log (3.5 KiB)

[totaam]

2019-11-30 01:47:17: mjlbach uploaded file OpenGL_check.log (4.9 KiB)

[totaam]

2019-11-30 01:47:42: mjlbach commented

---

Updated

[totaam]

2019-11-30 01:51:46: antoine commented

---

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?

[totaam]

2019-11-30 02:07:22: mjlbach uploaded file info.txt (139.0 KiB)

[totaam]

2019-11-30 15:46:17: antoine commented

---

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:

• why your client upscales things by 200%:

upscaled to 200%, virtual screen size: 640x400
 mjlbach-macbook-pro-2.local (339x212 mm - DPI: 47x47) workarea: 640x355 at 0x12
   monitor 2 (286x179 mm - DPI: 56x56)

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

• why the server chooses a DPI which does not look related to the scaled (47) or unscaled (95) client DPI!

display.dpi.default=0
display.dpi.value=36
display.dpi.x=36
display.dpi.y=36

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

[totaam]

2019-11-30 17:06:13: mjlbach commented

---

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

[totaam]

2019-11-30 17:06:29: mjlbach uploaded file :2.log (43.2 KiB)

[totaam]

2019-11-30 17:06:42: mjlbach uploaded file client_log.info (4.8 KiB)

[totaam]

2019-12-01 06:08:46: antoine commented

---

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:

• we honour the resolution request: client resolution is (640, 400), current server resolution is 8192x4096
• and the DPI requested:

set to 36 x 36
wanted: 36 x 36

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:

• default settings without any --dpi= overrides - should not be any different
• setting --dpi=144 on the command line, should now be double the size it was before with desktop-scaling
• also setting --desktop-scaling=no

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.

[totaam]

2019-12-01 06:14:11: mjlbach commented

---

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!

[totaam]

2019-12-01 06:32:24: mjlbach commented

---

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.

[totaam]

2020-03-03 12:47:50: antoine commented

---

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?

[totaam]

2020-03-03 15:54:37: mjlbach changed status from new to closed

[totaam]

2020-03-03 15:54:37: mjlbach set resolution to fixed

[totaam]

2020-03-03 15:54:37: mjlbach commented

---

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

[totaam]

2020-03-15 07:22:21: antoine commented

---

r24545 was incorrect and has been reverted in r25645.