shadow desktop scaling broken for scaling < 100%

[Lanchon]

Describe the bug shadow desktop scaling is broken when using --desktop-scaling < 100%. this issue is worked-around if --opengl=off is specified (but then bug https://github.com/Xpra-org/xpra/issues/4323 hits, so workaround is also unusable).

what happens when scaling < 100% is used is:

• in the server the desktop image is scaled down before encoding and transmitting. this seems to work correctly.
• in the client a scaled-down window of the correct size pops up.
• however the images from the server, once decoded, are SCALED UP before being drawn in the client window. this causes only the upper left part of the desktop to be visible. the resulting effective scale seems to be 1/f, where f is the requested scaling factor. for example, if f=0.5 then this happens:
  • a 50% sized (25% area) client window pops up (correct size).
  • the window is filled with the transmitted images blown up by a factor of 2 by length (of 4 by area). with respect to the original desktop images, which were halved before transmission, this effectively cancels the scaling (while still halving the resolution and transmitting only 1/4 of the original pixels).
  • given that the client window size is correctly halved in length and that the effective content size is the original desktop size, only 1/2 of the screen by length is seen in the horizontal an vertical directions (only 1/4 of the area is visible, the top left corner).
• while this happens, mouse events from the client to the server are scaled correctly (which means local mouse and local image as shown in the client are mismatched).
• if OpenGL is disabled in the client, the scaling problem disappears.

To Reproduce Steps to reproduce the behavior:

1. server command: none
2. client command: xpra shadow ssh:XXX:0 --desktop-scaling=70%
3. specific action to trigger the bug: none

System Information (please complete the following information):

• Server OS: Linux Mint 22 Wilma base: Ubuntu 24.04 noble
• Client OS: Linux Mint 22 Wilma base: Ubuntu 24.04 noble
• Xpra Server Version: xpra v6.1.1-r0
• Xpra Client Version: xpra v6.1.1-r0

Additional context on both sides: Desktop: Cinnamon v: 6.2.9 tk: GTK v: 3.24.41 wm: Muffin vt: 7 dm: LightDM v: 1.30.0 standard X11 session

client: Graphics: Intel Alder Lake-P GT2 [Iris Xe Graphics] vendor: Lenovo driver: i915 v: kernel arch: Gen-12.2

[totaam]

Can you try running version LTS 5.x instead? I have seen some corruption with opengl and scaling, bisected down to 8b73c2b181ec45eb2b79fcfab511da60a84067ed - this is one of the v6 key features, the v5.x branch should not be affected.

[totaam]

The fix is in 32d9008ce5be5071b30efaeca2e00ad53404ce40 + 617aa2e92bb6b10ed2e8b16c21b4341a77913a93 + 342dfa0bec7e6d16d3b277364bb0f52b160a209f

Works for me, this will be included in v6.1.2

[Lanchon]

Can you try running version LTS 5.x instead?

i downgraded only the client. opengl works but it downscales using nearest neighbor (no bilinear), so not really useful.

The fix is in 32d9008 + 617aa2e + 342dfa0

thanks! i will test once the fix is released. i'll come back to this issue in case of trouble.

[totaam]

i downgraded only the client. opengl works but it downscales using nearest neighbor (no bilinear), so not really useful.

In your case, the downscaling is done server-side, it should be possible to teach the module to use a different sampling algorithm when downscaling. Normally, this is driven by the speed option alone: https://github.com/Xpra-org/xpra/blob/474343fe09bf67ed7a73495e916af7e1c7028d2e/xpra/codecs/libyuv/converter.pyx#L183-L188

Another (less optimal) option would be to tell the server to not downscale before compression and let the opengl client apply the linear sampling: https://github.com/Xpra-org/xpra/blob/474343fe09bf67ed7a73495e916af7e1c7028d2e/xpra/opengl/backing.py#L566-L572

---

i will test once the fix is released.

I am afraid that I have found some more issues, so it could take a while.

[Lanchon]

for now im using v5.0.9-r0 client in non-GL mode against current 6.x server. it works fine like this (bilinear), so for me there is no need to debug the downscaling filtering in GL mode (unless you want to).

thanks again!

[totaam]

FYI: I have created a ticket for improving the scaling filters based on the window's content-type: #4326