Xpra: Ticket #2778: Screen is not updating during click-drag

"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



Tue, 26 May 2020 09:42:46 GMT - Antoine Martin: owner, description changed

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?


Tue, 26 May 2020 10:20:52 GMT - stdedos:

Unfortunately, usual suspects: gnome-terminal, Sublime Text/Merge, LibreOffice, PyCharm/Rubymine (although I don't think they affect any more than the rest) ...


Tue, 26 May 2020 10:23:25 GMT - Antoine Martin:

I've definitely tried libreoffice and I'm not seeing it. What am I missing?


Tue, 26 May 2020 11:31:24 GMT - stdedos:

Maybe it is a latency issue 😕

Yesterday it was PITA to work, today some things work, and some don't ... idk


Fri, 29 May 2020 13:11:09 GMT - stdedos: attachment set


Fri, 29 May 2020 13:13:00 GMT - stdedos: attachment set


Fri, 29 May 2020 15:05:59 GMT - Antoine Martin:

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.


Fri, 29 May 2020 17:44:04 GMT - stdedos:

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.


Fri, 29 May 2020 18:00:25 GMT - Antoine Martin:

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)


Mon, 13 Jul 2020 08:21:19 GMT - stdedos:

Does ticket:2752#comment:3 help this ticket in any way?


Mon, 16 Nov 2020 14:18:29 GMT - Antoine Martin: status changed; resolution set


Sat, 23 Jan 2021 06:00:34 GMT - migration script:

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