Window scaling is wrong when windows 10 scaling isn't the same between monitors

[simplypie]

Describe the bug
The image sharpness/quality is degraded when switching windows between monitors that have different scaling.

To Reproduce
Steps to reproduce the behavior:

1. server command
   On RHEL 8
   xpra start :10 --pulseaudio=no --start-via-proxy=no --opengl=auto --speaker=disabled --microphone=disabled --resize-display=yes --desktop-scaling=auto

2. client command
   On Windows 10 I connect over SSH using the GUI

3. specific action to trigger the bug
   On Windows, make the 'main display' have a scale and layout value other than 100%.

I show 150% on monitor 1 here:

Then when I move a window to a different display that is at 100%, the scaling is wrong, text looks blurry and zoomed out.

If I make the main display 100% scaling, then open xpra on the client, everything looks how I'd expect it to.

System Information (please complete the following information):

• Server OS: RHEL 8.9
• Client OS: Windows 10
• Xpra Server Version 5.0 (dnf update doesn't pull anything newer)
• Xpra Client Version 6.0

Additional context
Here are some before and after pictures, both of these screenshots are taken using monitor 2 using 100% scaling:

with 150% scaling on the main monitor (monitor 1):

With 100% scaling (This is how I want it to look always, regardless of the scaling on monitor 1)

It is most obvious in the ribbon drop down options and icons. I don't think the scaling on monitors that aren't being used to display the window should have any impact on the resolution/clarity of the image so I thought I'd file this issue. I think --desktop-scaling=auto is supposed to fix this but maybe I'm using it wrong.

It's easy to workaround by changing my scaling, opening the xpra client, then changing my scaling back. But it would be nice to not need to do that.

I also noticed that snapping/maximizing a window or using Win+arrow_keys will send the window offscreen, I'm not sure if that is related to the scaling or a separate issue entirely but it's also easy to workaround by dragging from the corner to expand it by hand.

[totaam]

I think --desktop-scaling=auto is supposed to fix this but maybe I'm using it wrong

Desktop scaling is global.

With the v6 clients, you may have better results with --opengl=force as the opengl backend will query the OS about the scaling of each window when rendering. (worth trying --opengl=no too)

Scaling is a PITA, especially on MS Windows because the OS is trying very hard to lie to us about the actual rendering resolution.
Forcing us to apply workaround after workaround to try to get the correct values.

[simplypie]

Hi, thanks for the quick response.

One thing I didn't mention in the original post was that I get this openGL error in my windows notifications when connecting, regardless of if I use opengl=force/auto/no

My laptop uses the integrated
Intel(R) Iris(R) Xe Graphics
from this processor
11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz 3.00 GHz
Driver version:
31.0.101.4887
I see there are slightly newer drivers for it but I don't want to mess with the OEM drivers on my work laptop.

I tried those other openGL options and still have the same issue. I stumbled on the workaround while making the bug report and after using it for awhile I think it's good enough for me since I don't need to restart my server/laptop that often.

If it's a lot of work to fix it then it's probably fine to close this, knowing the workaround is to make sure each windows monitor has a matching scaling amount to the 'main display' if openGL doesn't work.

[totaam]

Ah, none of the opengl options will work if opengl fails to load.
Can you please post the output of Xpra_cmd.exe opengl -d all

As for the per-monitor dpi, we meant to enable it with #3943 but I'm not entirely sure how that plays out with GTK, opengl, environment variables, etc

[simplypie]

Here is the output:
output.txt

This line stuck out to me
OpenGL accelerate missing: numpy_formathandler

I tried to import it using the Python_exec_cmd

$ ./Python_exec_cmd "from OpenGL_accelerate import numpy_formathandler"
Traceback (most recent call last):
  File "C:/msys64/mingw64/lib/python3.11/site-packages/cx_Freeze/initscripts/__startup__.py", line 138, in run
  File "C:/msys64/mingw64/lib/python3.11/site-packages/cx_Freeze/initscripts/console.py", line 17, in run
  File "xpra/platform/win32/scripts/exec.py", line 20, in <module>
  File "<string>", line 1, in <module>
ImportError: cannot import name 'numpy_formathandler' from 'OpenGL_accelerate' (C:/Program Files/Xpra/lib/OpenGL_accelerate/__init__.py)

I don't think those C:/msys64 paths actually exist on my machine.

I tried googling a bit and found some people had a similar problem in an older version of PyOpenGL and solved it by doing

pip uninstall PyOpenGL-accelerate
pip cache remove PyOpenGL*
pip install numpy
pip install PyOpenGL-accelerate

But I'm not sure how I'd source whatever python environment xpra uses to try and pip upgrade OpenGL_accelerate/numpy.

[totaam]

Here is the output:
(..)

GLU=1.2.2.0 Microsoft Corporation
accelerate=3.1.7
array-handlers=()
backend=win32
display_mode=DOUBLE
max-viewport-dims=16384, 16384
opengl=4.6
platform=win32
pyopengl=3.1.7
renderer=Intel(R) Iris(R) Xe Graphics
safe=True
shading-language-version=4.60 - Build 31.0.101.4887
success=True
texture-size-limit=16384
vendor=Intel
zerocopy=True

This looks absolutely fine.
I have no idea why it's failing when we run the same command in a subprocess.

Maybe show Xpra_cmd.exe attach -d opengl ....

This line stuck out to me
OpenGL accelerate missing: numpy_formathandler

This is optional and not an issue at all.

[simplypie]

Here is the output
attach_output.txt
I didn't notice any openGL errors in my windows messages when I opened/connected to it this way but I still have the issue with the blurriness/scaling being wrong if my main display has a different windows scaling.

[totaam]

How odd, no sign of the warning from this comment: #4205 (comment)
I'm not sure if your window was shown when this log sample was captured, but if it was, it was not using opengl for rendering - there can be many reasons for that, only some of which can be overriden with --opengl=force.

[simplypie]

Ah when I gave the previous output there was no window to display on the server. I'll go through my steps and maybe you can point out if I'm doing something wrong.

Normally:

1. I open Xpra on windows using the icon
2. Click connect
3. Use the GUI to type in my SSH settings and connect

This gives the error from #4205 (comment) regardless of the --opengl setting I pick on the server or if there are any windows to display.

For these new logs what I'm doing:

1. on the RHEL server, I started Xpra using xpra start :10 --pulseaudio=no --start-via-proxy=no --opengl=force --speaker=disabled --microphone=disabled --resize-display=yes --desktop-scaling=auto
2. I opened a LibreOffice Writer window (launched from the windows system tray xpra icon > start > office > writer)
3. disconnected from the server on windows
4. Using git bash for windows as a terminal in this directory /c/Program Files/Xpra, I ran ./Xpra_cmd.exe attach -d opengl ssh://username@hostname:22/10
5. On VSCode running on windows, but connected to a RHEL workspace using SSH, I have a terminal with

> echo $DISPLAY
:10.0

6. On that VsCode Terminal I opened another program that uses a GUI, I see it appear on windows

This flow doesn't show any errors in my system tray like when I use the GUI, here is the output of the Xpra_cmd:
xpraAttach.txt
I added a line that says *I open a new window from vscode here* So it was clear when I opened a new window in the log.

If openGL is working, it still doesn't fix the scaling issue or the fact that the fullscreen snaps go offscreen.

[totaam]

I open Xpra on windows using the icon
Click connect

Ah, that's using the GUI... Let me try that.

xpra start :10 --pulseaudio=no --start-via-proxy=no --opengl=force --speaker=disabled --microphone=disabled --resize-display=yes --desktop-scaling=auto

Simplified version of this long command: xpra start :10 --audio=no
Every other option is either redundant or the same as the default.

Using git bash for windows as a terminal...

FYI: You can also use cmd.exe.

If openGL is working,

It is, your log sample shows: OpenGL enabled on 'Intel(R) Iris(R) Xe Graphics'.

it still doesn't fix the scaling issue or the fact that the fullscreen snaps go offscreen.

Ah, sorry. It was worth a try.

[simplypie]

FYI: You can also use cmd.exe.

I tried it with cmd.exe and got the same results.

Ah, sorry. It was worth a try.

No worries I learned a bit more about xpra in the process and I have a workaround. I do think it could trip up new users though.

This command specifically is pretty useful to me
./Xpra_cmd.exe attach -d opengl ssh://username@hostname:22/10
So I can automate the connection using a command line AFTER my VPN is connected. The current auto-reconnect always throws an error for me since my VPN is still connecting. Also knowing where the debug info lives can be useful.

Thanks for your help!

[alexisshaw]

just wanted to comment that I still get the OpenGL loading error from the GUI in 6.0.1

[L0laapk3]

I've mentioned this in the discord, but I have a possibly related issue (clean windows + xpra install):

• When running Xpra.exe attach .., I get OpenGL Acceleration Failure: [WinError 6] The handle is invalid.
• When running Xpra_cmd.exe attach .., it successfully uses my Intel Iris Xe Graphics for OpenGL acceleration.

[totaam]

The commit above may help. At least it now allows Wayland clients to display the window with the correct scaling applied (#4242) and I have verified that the scaling can be changed dynamically so this should also handle the case where the window is moved to a monitor which uses a different scaling value - at least for Wayland clients.

With the non-opengl backend, we just paint with cairo and I'm not sure if cairo or the OS (or both!) do the actual scaling (it's complicated - see links), or what type of filter they apply when they do it.
With the opengl backend, the window scale factor is used when painting the window backing FBO onto the screen and the sampling filter chosen is GL_LINEAR:

xpra/xpra/client/gl/backing.py

Line 786 in 4c6ae20

sampling = GL_LINEAR if scaling else GL_NEAREST

For more information, see glBlitFramebuffer

Now this does not handle fractional scaling, so this may not help with the "150% scaling with MS Windows clients.
We still upscale the pixels rather than rendering at the client's native resolution.

Here are some relevant links for what MS Windows does:

• Improving the high-DPI experience in GDI based Desktop Apps
• High DPI Scaling Improvements for Desktop Applications and “Mixed Mode” DPI Scaling in the Windows 10 Anniversary Update (1607)

To be able to take advantage of these extra pixels, we would need to:

• know the exact and true resolution and scaling factor used by each monitor - really not easy at all, but probably doable somehow (PerMonitor dpiAwareness in manifest file #3943 was meant to help with that on MS Windows) - even if it conflicts with GTK's own adjusted geometries, and some OSes will still lie to us in some cases (be it through misconfiguration / conflict or intentional user overrides)
• configure the server's virtual displays to match (this should just work out of the box without any server-side changes)
• when painting, do the opposite of what we do now and only upscale or downscale if the window's scale factor is not the same as the monitor it's on (and when that happens, funky things will happen with the window geometry...)

I haven't even begun to look at what MacOS does, but it's bound to be problematic too.

@L0laapk3 Finally, as of the OpenGL Acceleration Failure - this is completely unrelated to this ticket.
I can reproduce it with Xpra-Launcher but not with Xpra_cmd launcher, so this is definitely a file descriptor issue.
I should have fix soon.
Though I did find other issues to fix in the meantime, ie: 7d269d4

[simplypie]

To be able to take advantage of these extra pixels, we would need to:

• know the exact and true resolution and scaling factor used by each monitor - really not easy at all, but probably doable somehow (PerMonitor dpiAwareness in manifest file #3943 was meant to help with that on MS Windows) - even if it conflicts with GTK's own adjusted geometries, and some OSes will still lie to us in some cases (be it through misconfiguration / conflict or intentional user overrides)

Would it be possible to give the user an option to manually enter their settings for each monitor?

[totaam]

Would it be possible to give the user an option to manually enter their settings for each monitor?

I am certainly not going to make it easier for users to mess things up. It's hard enough as it is.