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
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?
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?).
expected performance on 100Mbps lan
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):
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")
monotonic clock problems could explain some, but not all, of these problems: #2178
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2173