"Xpra-Python3-x86_64_4.1-r26463\xpra_cmd" attach ssh://user@ip/20 --ssh="plink -ssh -agent" --modal-windows=no --title="@title@ on @hostname@/@server-display@" --opengl=no --bandwidth-limit=6Mbps 2020-05-25 10:49:21,856 Xpra GTK3 client version 4.1-r26463 64-bit 2020-05-25 10:49:21,858 running on Microsoft Windows 10 2020-05-25 10:49:21,953 Warning: failed to import opencv: 2020-05-25 10:49:21,953 No module named 'cv2' 2020-05-25 10:49:21,953 webcam forwarding is disabled 2020-05-25 10:49:23,077 GStreamer version 1.16.2 for Python 3.8.3 64-bit 2020-05-25 10:49:23,696 keyboard layout code 0x409 2020-05-25 10:49:23,696 identified as 'United States - English' : us 2020-05-25 10:49:24,155 keyboard settings: layout=us 2020-05-25 10:49:24,160 desktop size is 4160x1440 with 1 screen: 2020-05-25 10:49:24,160 Default (1100x381 mm - DPI: 96x96) workarea: 4160x1400 2020-05-25 10:49:24,160 Generic PnP Monitor 1600x900 at 0x534 (309x174 mm - DPI: 131x131) workarea: 1600x860 2020-05-25 10:49:24,161 C32JG5x 2560x1440 at 1600x0 (697x392 mm - DPI: 93x93) workarea: 2560x1400 2020-05-25 10:49:24,958 Error: cannot find icon 'xpra' 2020-05-25 10:49:31,988 enabled remote logging 2020-05-25 10:49:31,992 Xpra GTK3 X11 server version 3.0.9-r26132 64-bit 2020-05-25 10:49:31,993 running on Linux Ubuntu 16.04 xenial 2020-05-25 10:49:32,007 Attached to ip:22 2020-05-25 10:49:32,008 (press Control-C to detach)
I also think sometime between r26160 / r26385 / r26463, the screen is not updating during click-drag; it somehow waits for the MouseUp event to fire.
My usecases are click-drag-highlight in gnome-terminal, and click-drag scroll bars
I can't reproduce any problems.
I can scroll the windows, drag to select, etc..
What am I missing? Are there any particular open-source applications that reproduce the problem?
Unfortunately, usual suspects: gnome-terminal, Sublime Text/Merge, LibreOffice, PyCharm/Rubymine (although I don't think they affect any more than the rest) ...
I've definitely tried libreoffice and I'm not seeing it. What am I missing?
Maybe it is a latency issue 😕
Yesterday it was PITA to work, today some things work, and some don't ... idk
Maybe it is a latency issue 😕
Looks like it, your server latency spiked at 28 seconds at some point! The damage latency is also quite high at 235ms average, so this could just be the screen updates taking their time before being shown rather than the click and drag not doing anything.
I have seen a relative slowness lately (nothing like what you're showing), even locally with mmap enabled, I don't know where this comes from.
Replying to Antoine Martin:
Maybe it is a latency issue 😕
Looks like it, your server latency spiked at 28 seconds at some point!
Yeah, story of my xpra experience (luckily, that is 10% of it)
Could you add something something with more statistics with regards to latency? qdirstat has very nice statistics (sadly, C++)
The damage latency is also quite high at 235ms average, so this could just be the screen updates taking their time before being shown rather than the click and drag not doing anything.
What is that?
I have seen a relative slowness lately (nothing like what you're showing), even locally with mmap enabled, I don't know where this comes from
That is also story of my work with xpra (~30%).
I just feel like saying it - thank you for having such an otherwise very well-thought and working software.
What is that?
The "damage latency" is how long it takes between the time the xpra server is notified by the X11 server that a screen update has occurred and the time we actually send the packet for this update. If it is this high, it's likely that xpra (wrongly?) is trying to avoid causing more bandwidth issues. (ie: reducing bandwidth usage following a latency spike)
Does ticket:2752#comment:3 help this ticket in any way?
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2778