Xpra: Ticket #2173: xpra gui hangs depending on Decoding Latency

It appears that GUI actions of xpra (specifically, tray actions) are dependent on Decoding Latency. With such high latencies (showed in the attachment), they appear to be "related" to xpra's responsiveness



Sun, 24 Feb 2019 17:48:58 GMT - stdedos: attachment set


Mon, 25 Feb 2019 05:32:32 GMT - Antoine Martin: owner changed

High decoding latencies (anything above 100ms) are not normal. How do I reproduce this?

The decoding latency is not usually interfering with the UI thread, most picture decoding is done in a dedicated thread and only calls back to the main UI thread for doing the actual painting to the screen. So it is likely that something else is interfering with the UI thread and that this is just a symptom. Maybe the clipboard? (#2172) Can you try one of the newer (hopefully fixed) builds, or disabling the clipboard and see if it helps?


Mon, 25 Feb 2019 06:01:53 GMT - stdedos:

Client: Xpra-Python3-x86_64_Setup_2.5-r21840, Win 10 Server:

2019-02-23 19:11:01,495 Xpra GTK2 X11 server version 2.5-r21791 64-bit
2019-02-23 19:11:01,496  running on Linux Ubuntu 16.04 xenial

(started with:) xpra_cmd shadow ssh://user@ip/0 --opengl=no --desktop-scaling=0.75 --webcam=no --speaker=off --microphone=off


Connecting with: xpra_cmd shadow ssh://user@ip/0 --clipboard=no --opengl=no --desktop-scaling=0.75 --webcam=no --speaker=off --microphone=off

does seem to fix the issue, but, it is still outside of your "expected delay" (see new screenshot).

I haven't done anything per se, except keep up with the beta builds (server/client). If there is any profiling build, I'd be happy to run a test run with it (or maybe some -d flag?).


Mon, 25 Feb 2019 06:02:10 GMT - stdedos: attachment set


Mon, 25 Feb 2019 07:20:51 GMT - Antoine Martin: attachment set

expected performance on 100Mbps lan


Mon, 25 Feb 2019 07:22:09 GMT - Antoine Martin:

I haven't done anything per se, except keep up with the beta builds (server/client). If there is any profiling build, I'd be happy to run a test run with it (or maybe some -d flag?).

The values are so far out of whack that something fundamental must be wrong. I just don't know what and I don't think profiling would show it.

This is what you should be seeing (captured on a 100Mbps LAN): expected performance on 100Mbps lan


Mon, 25 Feb 2019 07:32:11 GMT - stdedos:

On the shown scenarios it's not 100Mbps LAN.

The first one, is WiFi-over-4G The second one, is a wired 10Mbps over Internet.

Both connections are crossing IPSec VPN.

However, I assume that "decoding latency" metric is unaffected even by delay in packets delivery.

(I do need to note, however, I have no idea what 36.991 / 4.295 ms latencies are. Numbers seem exceedingly big, and I'd say unexpected. Server never crosses 4 load (on a 8-CPU system), and client appears also "unloaded")


Tue, 26 Feb 2019 06:32:44 GMT - Antoine Martin:

monotonic clock problems could explain some, but not all, of these problems: #2178


Thu, 14 Mar 2019 12:57:07 GMT - Antoine Martin: status changed; resolution set


Sat, 23 Jan 2021 05:44:09 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2173