search

Xpra-org / xpra

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

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

Open hxtmdev opened 1 day ago

hxtmdev commented 1 day ago

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):

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 commented 1 day ago

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: https://github.com/Xpra-org/xpra/issues/3816#issuecomment-1501793509, https://github.com/Xpra-org/xpra/issues/4243#issuecomment-2142584306.

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). : https://github.com/Xpra-org/xpra/issues/2248#issuecomment-765519117

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 commented 14 hours ago

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 commented 7 hours ago

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.