VSCodium window updates very laggy (~1s between updates)

[hxtmdev]

Describe the bug
VSCodium window updates are very laggy in an environment with direct 1 GBit/s ethernet where all other windows work just fine.

To Reproduce
Steps to reproduce the behavior:

1. xpra --dbus-launch= --dbus-control=no --ssh='ssh -o BatchMode=yes' --start-child='bash -c "xrdb -merge <(echo Xft.dpi: 120) ; tmux kill-server ; tmux start-server"' --opengl=no --webcam=no --pulseaudio=no --audio=no --av-sync=no --keyboard-sync=no --notifications=no --xsettings=no --bell=no --open-files=no --open-url=no --splash=no --forward-xdg-open=off --speaker=disabled --title='@title@ (remote)' start ssh://XXXXX@192.168.XXX.XXX/42
2. open VSCodium (or VSCode) and do anything, most annoying when scrolling

System Information (please complete the following information):

• Server OS: NixOS 24.05
• Client OS: Debian 12 bookworm
• Xpra Server Version v6.1.2 from this PR
• Xpra Client Version v6.1.2-r1

Additional context
Tried adding --encoding=no-scroll, --encoding=stream, removing the DPI part, codium --disable-gpu, VSCodium light theme, VSCode (not -ium) => no changes.
Observed delay between updates is circa 1 second.
Client runs inside firejail+Xephyr but that doesn't appear to be a problem as all other windows work very well.

Does this sound like an xpra / encoding problem or more likely something on VSCodium side? I think NixOS / packaging is unlikely when all other windows run smoothly?

[totaam]

xpra --dbus-launch= --dbus-control=no ... --no-... --no-..

Looks like you would be better off with --minimal=yes then enabling selectively the few options that you keep enabled.

--opengl=no

Try to enable this one. This can make massive difference to display performance.

vscode is based on electron, isn't it?
Electron apps have always had issues: #3816 (comment), #4243 (comment).

vscode specifically: Now I've enabled opengl on the client, and rstudio and atom are definitely more responsive when typing (newlines still cause hiccups, but I guess that's fine). : #2248 (comment)

Oh, and just in case this is caused by opengl rendering server-side (I have no idea how electron apps do their rendering). Try launching glxgears from a terminal.
If it shows up instantly, we're good, but on some systems with newer libraries you may see a one second delay as the opengl dispatch tries a few options before finding one that works - see #4349
When that happens, a decent workaround is to use vglrun to launch - if possible.

[hxtmdev]

Looks like you would be better off with --minimal=yes then enabling selectively the few options that you keep enabled.

Thanks! Missed that as it appears to be missing in the manpage.

Try to enable this one. This can make massive difference to display performance.

Tried it but saw no difference. Most likely because OpenGL is not available on my client though, the splash mentioned opengl failure. While it might help mitigate the symptoms I suspect the cause is elsewhere (see below).

Electron apps have always had issues: #3816 (comment), #4243 (comment).

Tried deleting the fallback rule and changing it to text / video, no changes.

If it shows up instantly, we're good

It did show up instantly.

Interestingly enough, running VSCodium "full screen" (as in one window covering most of the nested X server) within Xephyr (to get some drawing indirection) and firejail (for Xephyr convenience), using the same DPI settings, produced a smooth experience, albeit with compression artifacts. Now that I see it, I believe I might have had that experience a while ago on an earlier version. Does this ring enough bells or should I try to repro+bisect the server side?

firejail --x11=xephyr --xephyr-screen=2560x1384 bash -c 'echo $DISPLAY ; exec i3 &>/dev/null'
DISPLAY=:924 codium

--x11=xpra had the same problem as expected.

[totaam]

Thanks! Missed that as it appears to be missing in the manpage.

Added in 37b1d13

Most likely because OpenGL is not available on my client though,

It should be available pretty much everywhere.

the splash mentioned opengl failure.

What failure?

---

try to repro+bisect

That would be way down the list of things to try. See https://github.com/Xpra-org/xpra/wiki/Reporting-Bugs
Running with -d damage,compress would be a good start.
Having xpra info would help too.

[hxtmdev]

tl;dr: --refresh-rate=60

---

What failure?

No OpenGL_accelerate module loaded: No module named 'OpenGL_accelerate'
[...]
OpenGL accelerated rendering is not available:
 renderer 'llvmpipe (LLVM 15.0.6, 256 bits)' is blacklisted!

See https://github.com/Xpra-org/xpra/wiki/Reporting-Bugs

--encodings= rgb/rgb24/png did not change anything.

Running with -d damage,compress would be a good start.

Changes nothing, full initial log:

(xpra:96): dbind-WARNING **: 17:54:39.793: AT-SPI: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: org.freedesktop.DBus.Error.ServiceUnknown
2024-09-25 17:54:39,877 Xpra GTK3 X11 client version 6.1.2-r1
2024-09-25 17:54:39,883  running on Linux 6.1.0-23-amd64
2024-09-25 17:54:39,883  cpython 3.11
2024-09-25 17:54:39,883  window manager is 'i3'
2024-09-25 17:54:39,907 created unix domain sockets:
2024-09-25 17:54:39,907  '/home/daniel/xdg/xpra/clients/x1-96'
2024-09-25 17:54:40,085  keyboard settings: rules=evdev, model=pc105, layout=eu
2024-09-25 17:54:40,089  desktop size is 2560x1412:
2024-09-25 17:54:40,090   :726.0 (867x478 mm - DPI: 75x75)
found existing display 42 : LIVE
2024-09-25 17:54:40,965 enabled remote logging
2024-09-25 17:54:40,967 Xpra X11 seamless server version 6.1
2024-09-25 17:54:41,076 running, 2 windows
2024-09-25 17:54:43,473 Error: cannot access the list of printers
2024-09-25 17:54:43,473  failed to connect to server

(-d all did produce tons of output so I probably didn't mess up the -d).
To clarify: By artifacts I meant washed out colors etc., nothing wild like the partially green window in the other issue.

Having xpra info would help too.

info.txt, opened Firefox for reference

---

Surprisingly enough, ChatGPT of all things suggested --refresh=60 (in between a whole lot of nonsense), according to xpra --help that means --refresh-rate=60 and that did indeed fix my problem! It becomes effective when attaching to the running server with the setting and remains effective even when attaching without the setting afterwards.

Side note: This is missing in the man page again. Would it make sense to generate the man page programmatically? (Or kill it completely to force users into the up-to-date --help?)

Thanks for your help @totaam!

I now have a workaround that seems to completely solve my particular problem, feel free to either close this or leave it open to track the potential heuristic improvement that could make this manual setting obsolete.

If more info is needed on this or me verifying a fix would help, let me know.

[totaam]

No OpenGL_accelerate module loaded: No module named 'OpenGL_accelerate'

That's your distro package missing the accelerate extension, not ideal, but not that big of an issue.

renderer 'llvmpipe (LLVM 15.0.6, 256 bits)' is blacklisted!

Is this some kind of VM?
This is the software OpenGL renderer.

that means --refresh-rate=60 and that did indeed fix my problem!

That's odd.
It means that the correct refresh rate is not detected properly.
It obviously works fine here (and I have never seen it not detected properly):

$ python ./xpra/platform/gui.py  | grep refresh-rate
    - refresh-rate                : 59996

What do you get on the client?

[hxtmdev]

Is this some kind of VM?
This is the software OpenGL renderer.

yes, see initial description:

Client runs inside firejail+Xephyr but that doesn't appear to be a problem as all other windows work very well.

---

What do you get on the client?

$ python3 /usr/lib/python3/dist-packages/xpra/platform/gui.py | grep refresh-rate
(GUI-Properties:184): dbind-WARNING **: 07:42:46.895: AT-SPI: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: org.freedesktop.DBus.Error.ServiceUnknown
    - refresh-rate                : 0

xrandr for example is not available in that environment, adding it did not fix it but revealed that to the xrandr CLI the current refresh rate also looks like 2560x1412 0.00* as opposed to 2560x1440 59.95*+ outside of firejail+Xephyr. That could explain where the 0 comes from.
What I don't get is why it only affects VSCodium while all other applications like Firefox run without any issues.

[totaam]

Looks like a bug in Xephyr. 0Hz is not a valid config.

What I don't get is why it only affects VSCodium while all other applications like Firefox run without any issues.

My guess is that vscode uses the browser content-type and switches to video mode to accommodate it, the video pipeline uses the refresh rate as framerate, and this is the result.

[hxtmdev]

Looks like a bug in Xephyr. 0Hz is not a valid config.

There seems to be a default of 50Hz in the xpra code.
Would it make sense to use that as a fallback for obviously broken setups that report 0Hz for whatever reason? Maybe with a warning? Do you want me to open a PR for that?

[totaam]

IIRC, we already clamp the refresh rate, which is why you get 1Hz rather than 0Hz.