xpra icon
Bug tracker and wiki

Opened 12 days ago

Last modified 10 days ago

#2500 new defect

Text scaling regression in 4.0 macOS client

Reported by: mjlbach Owned by: mjlbach
Priority: major Milestone: 4.0
Component: client Version: 4.0.x
Keywords: Cc:

Description

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.

Attachments (8)

Screen Shot 2019-11-29 at 9.50.22 AM.png (1.0 MB) - added by mjlbach 12 days ago.
Screen Shot 2019-11-29 at 8.31.26 AM.png (1.1 MB) - added by mjlbach 12 days ago.
4.0.x
client_log.txt (2.9 KB) - added by mjlbach 12 days ago.
gtk_info.log (3.5 KB) - added by mjlbach 12 days ago.
OpenGL_check.log (4.9 KB) - added by mjlbach 12 days ago.
info.txt (139.0 KB) - added by mjlbach 12 days ago.
:2.log (43.2 KB) - added by mjlbach 11 days ago.
client_log.info (4.8 KB) - added by mjlbach 11 days ago.

Change History (16)

Changed 12 days ago by mjlbach

Changed 12 days ago by mjlbach

4.0.x

comment:1 Changed 12 days ago by Antoine Martin

Owner: changed from Antoine Martin to mjlbach

Looks like an exact duplicate of #2480.

Please post:

Changed 12 days ago by mjlbach

Attachment: client_log.txt added

Changed 12 days ago by mjlbach

Attachment: gtk_info.log added

Changed 12 days ago by mjlbach

Attachment: OpenGL_check.log added

comment:2 Changed 12 days ago by mjlbach

Updated

comment:3 Changed 12 days ago by 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?

Changed 12 days ago by mjlbach

Attachment: info.txt added

comment:4 Changed 11 days ago by 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:

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

comment:5 Changed 11 days ago by mjlbach

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

Changed 11 days ago by mjlbach

Attachment: :2.log added

Changed 11 days ago by mjlbach

Attachment: client_log.info added

comment:6 Changed 10 days ago by 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:

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

Last edited 10 days ago by Antoine Martin (previous) (diff)

comment:7 Changed 10 days ago by 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!

comment:8 Changed 10 days ago by 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.

Last edited 10 days ago by mjlbach (previous) (diff)
Note: See TracTickets for help on using tickets.