xpra gui hangs depending on Decoding Latency

[totaam]

Issue migrated from trac ticket # 2173

component: client | priority: major | resolution: needinfo

2019-02-24 17:48:49: stdedos created the issue

---

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

[totaam]

2019-02-24 17:48:59: stdedos uploaded file Xpra-latency_cmd_2019-02-24_19-44-13.png (25.5 KiB)

[totaam]

2019-02-25 05:32:33: antoine changed owner from antoine to stdedos

[totaam]

2019-02-25 05:32:33: antoine commented

---

[[Image(Xpra-latency_cmd_2019-02-24_19-44-13.png)]]

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?

[totaam]

2019-02-25 06:01:53: stdedos commented

---

Client: Xpra-Python3-x86_64_Setup_2.5-[r21840](../commit/2ff2aa0443133190122eeb2186cf9bfcd0c9a96c), Win 10
Server:

2019-02-23 19:11:01,495 Xpra GTK2 X11 server version 2.5-[r21791](../commit/a052b144e8aca1f688c7376a455c0ce83097ea9b) 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?).

[totaam]

2019-02-25 06:02:11: stdedos uploaded file xpra-high-decode_2019-02-25_07-54-57.png (22.6 KiB)

[totaam]

2019-02-25 07:20:51: antoine uploaded file lan100mbps.png (78.7 KiB)

expected performance on 100Mbps lan

[totaam]

2019-02-25 07:22:10: antoine commented

---

[[Image(xpra-high-decode_2019-02-25_07-54-57.png)]]

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):
[[Image(lan100mbps.png)]]

[totaam]

2019-02-25 07:32:12: stdedos commented

---

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

[totaam]

2019-02-26 06:32:44: antoine commented

---

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

[totaam]

2019-03-14 12:57:07: antoine changed status from new to closed

[totaam]

2019-03-14 12:57:07: antoine set resolution to needinfo