xpra icon
Bug tracker and wiki

Opened 3 weeks ago

Last modified 4 days ago

#1921 new defect

Local xpra is extremely laggy

Reported by: Thomas Martitz Owned by: Thomas Martitz
Priority: major Milestone: 2.4
Component: keyboard Version: 2.3.x
Keywords: Cc: steved424@…

Description

Local xpra is *very* laggy. The most prominent issue is that keyboard input is delayed by about a second, but also scrolling in GTK apps is laggy (might be caused by input lag, though).

As per IRC, I already tried debugging both client and server with -d keyboard,pointer and it does show that the server receives events delayed.

I also ran the server under strace, as I thought it might be blocked in some poll() loop, but that looked fine (all poll() calls return almost immediately.

Attachments (5)

info.txt.zip (46.1 KB) - added by Thomas Martitz 3 weeks ago.
info by bug report tool
xpra-info.txt (135.0 KB) - added by Thomas Martitz 4 days ago.
xpra-showconfig.txt (9.0 KB) - added by Thomas Martitz 4 days ago.
env.txt (2.5 KB) - added by Thomas Martitz 4 days ago.
:10.log (97.3 KB) - added by Thomas Martitz 4 days ago.

Download all attachments as: .zip

Change History (14)

Changed 3 weeks ago by Thomas Martitz

Attachment: info.txt.zip added

info by bug report tool

comment:1 Changed 3 weeks ago by Antoine Martin

Milestone: 2.4
Owner: changed from Antoine Martin to Thomas Martitz

Since it isn't laggy for anyone else (that I know of), please add more details as per wiki/ReportingBugs so we can identify the difference with your setup.

comment:2 Changed 3 weeks ago by Thomas Martitz

I attached the zip that's created by the built-in bug report took. What else do you need?

comment:3 Changed 3 weeks ago by tc424

Cc: steved424@… added

comment:4 Changed 3 weeks ago by Antoine Martin

What else do you need?

There are many questions on the wiki/ReportingBugs page, it is impossible for us to know which ones will be relevant. They key point is what something is different on your setup.

comment:5 Changed 4 days ago by Thomas Martitz

So I made a completely fresh Kubuntu 18.04.1 install and the behavior is pretty much the same. But as part of answering the question I found that disabling AV sync makes a huge difference, basically I cannot say it's laggy anymore.

what operating system is used on both the client and server, including the full version details

$ uname -a
Linux tmartitz-pc 4.15.0-30-generic #32-Ubuntu SMP Thu Jul 26 17:42:43 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ glxinfo | grep GL\ renderer
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2)

Kubuntu 18.04.1 comes with KDE Frameworks 5.44, Plasma 5.12 LTS and KDE Applications 17.12.3

$ dpkg -s xpra
Package: xpra
Status: install ok installed
Priority: optional
Section: x11
Installed-Size: 15697
Maintainer: Antoine Martin <antoine@devloop.org.uk>
Architecture: amd64
Version: 2.3.2-r19729-1
Replaces: ffmpeg-xpra
Depends: python (<< 2.8), python (>= 2.7~), python:any (<< 2.8), python:any (>= 2.7.5-5~), libavcodec57 (>= 7:3.4.2) | libavcodec-extra57 (>= 7:3.4.2), libavformat57 (>= 7:3.4.2), libavutil55 (>= 7:3.4.2), libc6 (>= 2.14), libglib2.0-0 (>= 2.12.0), libgtk2.0-0 (>= 2.24.0), libpam0g (>= 0.99.7.1), libswscale4 (>= 7:3.4.2), libsystemd0, libturbojpeg, libvpx5 (>= 1.6.0), libwebp6 (>= 0.5.1), libx11-6 (>= 2:1.2.99.901), libx264-152, libxcomposite1 (>= 1:0.3-1), libxdamage1 (>= 1:1.1), libxext6, libxfixes3, libxi6 (>= 2:1.2.99.4), libxkbfile1, libxrandr2 (>= 2:1.2.99.2), libxtst6, python-gtk2, x11-xserver-utils, xserver-xorg-video-dummy, python-gtkglext1, python-opengl, python-numpy, python-pil, python-rencode, python-lz4
Recommends: libavcodec57, libx264-148, dbus-x11, python-dbus, python-setproctitle, python-cryptography, python-kerberos, python-gssapi, gstreamer1.0-pulseaudio, gstreamer1.0-alsa, gstreamer1.0-plugins-base, gstreamer1.0-plugins-good, gstreamer1.0-plugins-ugly, python-gst-1.0, cups-filters, cups-common, cups-pdf, python-cups, python-pyinotify, python-opencv, v4l2loopback-dkms, openssh-client, ssh-askpass, websockify, libjs-jquery, keyboard-configuration, sshpass
Suggests: openssh-server, gnome-shell-extension-top-icons-plus, pulseaudio, pulseaudio-utils, python-avahi, python-netifaces, python-yaml, python-pycuda, libnvidia-encode1, python-lzo, libxvidcore4
Conflicts: ffmpeg-xpra
Conffiles:
 /etc/dbus-1/system.d/xpra.conf d58c2d718e3eaa799ed0223ab21dd2a5
 /etc/default/xpra 691afa8edec7c167de80fcfd407b0b37
 /etc/pam.d/xpra eaf372a294b1e2e1a1c9123cdeb03a41
 /etc/xpra/conf.d/05_features.conf f8bbd7527e86e50d2fe542470a14243e
 /etc/xpra/conf.d/10_network.conf 9549d386ce697a16e6e4edbc425466e3
 /etc/xpra/conf.d/12_ssl.conf 916ae779caa1a9e4ff3eb00cf9881ccc
 /etc/xpra/conf.d/15_file_transfers.conf 3d8e892d0b1b8ced4da21feac3a87e0f
 /etc/xpra/conf.d/16_printing.conf 55ded8177f08ff99629c34ef059ca163
 /etc/xpra/conf.d/20_sound.conf e805d4bd159a849529e3bc199e8958ea
 /etc/xpra/conf.d/30_picture.conf 2568844319ae92e81e3f3d14feb7c16a
 /etc/xpra/conf.d/35_webcam.conf 9f8857105624a48948078906acebf4ee
 /etc/xpra/conf.d/40_client.conf 2756819619b5c97839e680b3d19aaab0
 /etc/xpra/conf.d/42_client_keyboard.conf f1be5c9d8ef62d2677f1351ee4709ac8
 /etc/xpra/conf.d/50_server_network.conf 396e24f643bf3279360e74afa367fe84
 /etc/xpra/conf.d/55_server_x11.conf 82a4f3a74d998512955f2ca749172a76
 /etc/xpra/conf.d/60_server.conf 09fe862cd1ea649ddcbfcc7e04cde92e
 /etc/xpra/conf.d/65_proxy.conf a8d85747e0a2886341493a07977c390b
 /etc/xpra/cuda.conf 903827a1fd15d11fb4460ce2fc15c653
 /etc/xpra/xorg-uinput.conf 2913f509d04b5cf4432d356716874b95
 /etc/xpra/xorg.conf 4b6c318aef446f6585c83caee678880a
Description: tool to detach/reattach running X programs
 Xpra gives you the functionality of GNU Screen for X applications.
 .
 It allows the user to view remote X applications on their local machine, and
 disconnect and reconnect from the remote machine without losing the state of
 the running applications.
 .
 Unlike VNC, these applications are "rootless".  They appear as individual
 windows inside your window manager rather than being contained within a single
 window.
Homepage: http://xpra.org/

changes made to the default configuration, if any. This can be shown with the command: "xpra showconfig"

I have cleared all custom config. xpra showconfig is attached.

the desktop environment, window manager used - if applicable

KDE with kwin (see above)

anything that would make the setup unusual: number of screens, resolution, virtualization software, access via another remote desktop tool (VNC, RDP, ..), etc

I normally use 3 screens, one of them rotated, but the behavior is the same with only one output. No other remote desktop involved.

the network setup, bandwidth constraints (ie: LAN or DSL)

local

the full command lines used both on the server and client

$ ps aux | grep xpra
tmartitz  3075  5.4  1.5 1338604 369492 ?      Sl   10:44   4:19 /usr/bin/python2 /usr/bin/xpra start :10 --start-via-proxy=no
tmartitz  3076  0.0  0.8 880552 205320 ?       Ssl  10:44   0:04 /usr/lib/xorg/Xorg-for-Xpra-:10 -noreset -novtswitch -nolisten tcp +extension GLX +extension RANDR +extension RENDER -auth /home/tmartitz/.Xauthority -logfile /run/user/1000/xpra/Xorg.:10.log -configdir /run/user/1000/xpra/xorg.conf.d/3075 -config /etc/xpra/xorg.conf -depth 24 :10
tmartitz  3122  2.3  0.0 326532  8404 ?        S<l  10:44   1:52 pulseaudio --start -n --daemonize=false --system=false --exit-idle-time=-1 --load=module-suspend-on-idle --load=module-null-sink sink_name="Xpra-Speaker" sink_properties=device.description="Xpra\ Speaker" --load=module-null-sink sink_name="Xpra-Microphone" sink_properties=device.description="Xpra\ Microphone" --load=module-native-protocol-unix socket=/run/user/1000/xpra/pulse-:10/pulse/native --load=module-dbus-protocol --load=module-x11-publish --log-level=2 --log-target=stderr --enable-memfd=no
tmartitz  3604  5.3  1.7 2121604 438064 pts/1  Sl+  10:44   4:10 /usr/bin/python2 /usr/bin/xpra attach :10
tmartitz  3683  6.4  0.1 1215724 40680 pts/1   Sl+  10:45   5:03 /usr/bin/python2 /usr/bin/xpra _sound_play - -   opus  1.0
tmartitz  3722 12.4  0.1 1009540 40980 ?       Sl   10:45   9:44 /usr/bin/python2 /usr/bin/xpra _sound_record - - pulsesrc device=Xpra-Speaker.monitor opus  1.0
tmartitz  3756  0.0  0.0  25840  6768 ?        Ss   10:45   0:00 /usr/bin/python2 /usr/bin/xpra_signal_listener
tmartitz  5512  0.0  0.0  14780  1048 pts/3    S+   12:03   0:00 grep xpra

the server log file (or output if no log file is used)

:10.log is attached

the environment (ie: %PATH% on MS Windows, $PATH and $LD_LIBRARY_PATH on Linux, etc)

env.txt is attached

"xpra info" for the session

xpra-info.txt is attached

how the software was installed and what version (in full)

I installed it through package managers using the repositories on winswitch.org, version see above (latest stable)

is this a new problem or a regression? (if a regression, when did it start?)

I think it wasn't that bad a couple of years ago, but it's like this since a long time by now (I was too lazy to report early and hoped it would be fixed by the new graphics stack in 18.04)

are there other bugs that are similar?
are there other unusual issues / behaviour apart from this particular bug?

Not that I can tell for both questions

is it reproducible reliably? and if so, how?

Always

does this happen with all picture encodings?

Can't change with local xpra

does switching off certain features make a difference (ie: sound, opengl, clipboard)

Actually, this question gave a key hint. I did play with some settings, and disabling audio-video sync makes a huge difference. I would say the laggy behavior does not occur with AV sync disabled!

include relevant parts of the log files - including enough context to investigate (not just the last line showing the error message, but not necessarily the whole log file either)

What log files would be relevant?

does re-connecting help?

No

does it happen with other type of clients (different OS, etc)

I have only Linux clients. I have one at home (for home office) and it's laggy as well but I can't say for sure it's not the slow internet connection.

try to include the output of some of the diagnosis tools we bundle (ie: Network_Info.exe and Encoding_Info.exe on MS Windows, net_util.py and loader.py everywhere else)

Please say if this is still relevant after my AV sync finding.

Last edited 4 days ago by Antoine Martin (previous) (diff)

Changed 4 days ago by Thomas Martitz

Attachment: xpra-info.txt added

Changed 4 days ago by Thomas Martitz

Attachment: xpra-showconfig.txt added

Changed 4 days ago by Thomas Martitz

Attachment: env.txt added

Changed 4 days ago by Thomas Martitz

Attachment: :10.log added

comment:6 Changed 4 days ago by Thomas Martitz

Sorry, I have to take the av-sync finding back. I made an error on my side. Disabling av-sync *does not* do anything.

comment:7 Changed 4 days ago by Thomas Martitz

But perhaps you can tell if it's truly disabled because to me it looks still like being enabled?

$ xpra info | grep av-sync
client.argv=('/usr/bin/xpra', 'attach', '--av-sync=no', ':10')
client.av-sync=True
client.av-sync.client=0
client.av-sync.delta=0
client.av-sync.enabled=False
client.av-sync.total=75
features.av-sync=True
window.1.av-sync.current=75
window.1.av-sync.enabled=True
window.1.av-sync.target=75
window.9.av-sync.current=75
window.9.av-sync.enabled=True
window.9.av-sync.target=75
window.10.av-sync.current=0
window.10.av-sync.enabled=True
window.10.av-sync.target=0
Last edited 4 days ago by Antoine Martin (previous) (diff)

comment:8 Changed 4 days ago by Antoine Martin

KDE with kwin (see above)

I doubt that's the source of the problem, but if nothing else helps then it would be worth trying a different WM as I very rarely test the client under KDE.

Actually, this question gave a key hint. I did play with some settings, and disabling audio-video sync makes a huge difference. I would say the laggy behavior does not occur with AV sync disabled!

Then that's the problem.
What I don't understand is why you would have AV sync with local connections. Those are meant to use mmap, and mmap is not affected by av-sync.
The only encodings that use av-sync are the video encodings (vp8, vp9, h264 and hevc), and those don't usually trigger unless the application you run is refreshing at a high framerate.
What is the application you are forwarding?
Does the problem manifest itself with a simple xterm?

Can you try to turn off audio completely? Start with --speaker=no --microphone=no

Please say if this is still relevant after my AV sync finding.

I think there's enough data in this ticket, thanks!

comment:9 Changed 4 days ago by Thomas Martitz

Actually, this question gave a key hint. I did play with some settings, and disabling audio-video sync makes a huge difference. I would say the laggy behavior does not occur with AV sync disabled!

Then that's the problem.

av-sync is *not* the problem, the previous post was based on an error on my side (the window I tested wasn't running under xpra).

Note: See TracTickets for help on using tickets.