Xpra-org / xpra

Persistent remote applications for X11; screen sharing for X11, MacOS and MSWindows.
https://xpra.org/
GNU General Public License v2.0
2k stars 171 forks source link

Using xpra client on a wayland host with display scaling results in blurry windows #3994

Open callegar opened 1 year ago

callegar commented 1 year ago

Describe the bug

Launching xpra start ... on an X11 host. Trying to use xpra attach ... on a wayland client with display scaling (150%). Windows get displayed on the wayland machine but are a bit blurry (in any case readable). The --dpi option also seems to do nothing.

To Reproduce See description

System Information (please complete the following information):

totaam commented 1 year ago

Manjaro is not a supported distro.

on a wayland client with display scaling (150%)

What does this mean, where is it configured?

Please include a screenshot.

callegar commented 1 year ago

For what concerns xpra, manjaro should appear just like arch (which I guess is also an unsupported distro...)

Using KDE the wayland compositor lets you set a scaling factor for HiDPI displays. On the client I have it set to use 150% scaling, with an option to let legacy X11 applications do the scaling by themselves. The alternative would be do system scaling of X11 applications, which implies having Xwayland doing the scaling of otherwise unscaled apps. The latter necessarily results in some blur.

I'll attach a screenshot as soon as I am on the affected machine.

totaam commented 1 year ago

with an option to let legacy X11 applications do the scaling by themselves

What / where is this?

The alternative would be do system scaling of X11 applications

xpra does not use Xwayland on the client.

totaam commented 1 year ago

Xpra Server Version 4.5.1

This version does not exist!

callegar commented 1 year ago

Sorry for the typo, that was 4.4.5

totaam commented 11 months ago

FWIW: under Wayland, xpra does not use X11 at all. So the 150% scaling should be handled by Wayland and I'm not sure if there is an API for us to get the true dimensions of the window and the scaling factor to use with it.

callegar commented 7 months ago

Thanks for the info. Before further reporting, I have managed updating my system so that the reporting can be meaningful. I am now on xpra 6.0 on both the local machine and the remote one. This took some time because for some reason arch linux is stuck at 4.4.5 (strange as it may seem for a rolling distro). So now I am building my own xpra package for arch/manjaro and I hope I am doing it correctly.

Now, with a more recent xpra I can run it without the need to force it to X11 mode on the local host via the XDG_SESSION_TYPE=x11 environment variable. So far so good.

The problem is that the windows from the remote host remain extra blurry. This is an issue, specifically for terminal (konsole in my case) windows, where reading the text is possible but painful (to the extent of physical rather than metaphorical headaches). I believe that this depends on my specific situation where the remote machine is not HiDPI, but the local one is with desktop scaling set to 150%. My understanding is that xpra is unaware of this scaling (does 100%) that is done by the composer (that scales up to 150%) causing all the blurryness. I know that fractional scaling on wayland is a quite complicate thing if not worse, however, I understand that in order to provide a crisp display there is a way for wayland applications to know that the scaling is applied so that they can provide higher resolution rasters before the scaling. Waypipe seems to provide a more crisp display for konsole, so there should be a way to do it (obviously using waypipe in place of xpra is not an option, because xpra does much more and can deal with X11 applications).

As a final note, an interesting thing is that when you start xpra on the local host it says:

desktop size is 1707x1067:
2024-05-04 10:00:40,272   wayland-0 (300x190 mm - DPI: 145x143)

Here the 300x190mm is correct. However the 1707x1067 is the display resolution adjusted for the scaling. The real resolution is 2560x1600 and the 1707x1067 is actually the real resolution divided by 1.5 (150%). As a consequence the computed DPI is wrong. The real one is > 200dpi.

callegar commented 7 months ago

I have noticed that running xpra with --desktop-scaling=0.5 seems to get a crisp enough display at the correct scale. When you connect to the remote host you get an extra small konsole, but if you type konsole in it, then in the new window everything seems to be adjusted properly scale-wise.

Where does the 0.5 come from? Cannot really understand. 1/1.5 should be 0.667. So this looks like the ratio between the standard 96dpi and the actual ~200 dpi of my screen (can this be the case?). With 0.667 everything is definitely too large.

Unfortunately, with the desktop scaling at 0.5 there are other issues. When I scroll down the konsole and I get to the end, the konsole does not scroll but displays a messed up bottom line, until I scroll more... So there seems to be some rounding issue in understanding when the konsole should actually scroll.

totaam commented 3 months ago

See also: #4331 and #4326

donaldsycamore commented 1 month ago

I see the same issue with Debian Bookworm / GNOME 3 / Wayland. Fractional scaling is turned on in GNOME 3. On all my monitors, Xpra is blurry; on my High DPI monitors, I'm seeing a lower resolution image being upscaled.

2024-10-21 09:39:14,302 Xpra GTK3 Wayland client version 6.2.0-r0
2024-10-21 09:39:14,319  running on Linux Debian 12 bookworm
2024-10-21 09:39:14,319  cpython 3.11
2024-10-21 09:39:14,319  window manager is 'GNOME'

On client startup, the "desktop size" shown in the logs is not in raw pixels. The monitors vary between 4K (the two DELL S2721QSes and the SHP 0x1551) and 1080P (MSI MP161), with different scaling factors on each one (fractional scaling on the SHP 0x1551).

2024-10-21 09:39:17,719  desktop size is 3840x1944:
2024-10-21 09:39:17,719   wayland-0 (1830x710 mm - DPI: 53x70)
2024-10-21 09:39:17,719     DEL DELL S2721QS 1920x1080 at    0x0    (600x340 mm - DPI: 81x81) workarea: 1920x1080
2024-10-21 09:39:17,719     DEL DELL S2721QS 1920x1080 at 1920x0    (600x340 mm - DPI: 81x81) workarea: 1920x1080 at 1920x0
2024-10-21 09:39:17,719     SHP 0x1551       1280x800  at  640x1080 (290x180 mm - DPI: 112x113) workarea: 1280x800  at  640x1080
2024-10-21 09:39:17,719     MSI MSI MP161    1536x864  at 1920x1080 (340x190 mm - DPI: 115x116) workarea: 1536x864  at 1920x1080

The logs also contain a lot of (Xpra:3308724): Gtk-CRITICAL **: 09:39:18.203: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed.

If I run the client with --dpi=144, the text/etc in my windows gets bigger but the windows themselves are still as blurry as they ever were.

totaam commented 1 month ago

Since GTK has no plans to support fractional scaling, it is not exposing the actual window dimensions to us, the only way I can think of to fix would be to get the fractional scaling value from somewhere else then transform all coordinates (but per monitor!) before sending them to the server. The rendering would have to be done using the actual dimensions, not the ones from GTK. This is dumb because the actual coordinates do exist, and this may well trigger all sorts of interesting new bugs - starting with rounding errors...

So don't hold your breath. I don't think this is going to happen. Even if GTK5 eventually supports fractional scaling, it might just be easier to drop GTK at this point since GTK4 is a non-starter anyway: #1977 - see also #3871