Xpra: Ticket #2545: Slow update when editing

An emacs window on the remote is very slow to update edits. When I edit characters on a line in a text file in emacs, the change often isn't reflected on the screen for several seconds. It is updated promptly if I move the cursor to an adjacent line.

Version on the local machine: xpra v3.0.5-r24928 On the remote: xpra v3.0.5-r24928

The log for the period yesterday when I was experiencing the problem shows many lines like: 2020-01-09 16:52:27,895 Warning: more than 30 clipboard requests per second! There are some today, but not as many, and the problem is not as bad today.



Fri, 10 Jan 2020 11:20:04 GMT - Anthony Stone: attachment set

bug report


Fri, 10 Jan 2020 13:25:53 GMT - Antoine Martin: owner changed

Does turning the clipboard off fix the problems? Those warnings are very suspicious:

Warning: more than 30 clipboard requests per second!

Do you have a clipboard manager? A tool like synergy perhaps? Or maybe a virtual machine clipboard tool?


Fri, 10 Jan 2020 17:08:24 GMT - Anthony Stone:

No, disabling the clipboard doesn't fix it.

I don't use a clipboard manager -- perhaps I should.


Fri, 10 Jan 2020 17:27:08 GMT - Antoine Martin:

I don't use a clipboard manager -- perhaps I should.

Not if you can avoid it. Those things cause endless problems.

Something is constantly requesting the contents of the clipboard, figure out what it is and you can solve your problem. This is causing a huge amount of traffic and hogging the main thread.

If there's nothing obvious, please run the client and server with -d clipboard and post the log.


Mon, 13 Jan 2020 10:58:32 GMT - Anthony Stone: attachment set

/run/user/1013/xpra/:1.log


Mon, 13 Jan 2020 11:01:46 GMT - Anthony Stone:

I haven't been able to work out what might be using the clipboard excessively. I started xpra with -d clipboard and carried out some minor edits of a text file on the remote using emacs. The slow update behaviour was apparent during these edits. I have attached the log for this session.


Mon, 20 Jan 2020 11:14:54 GMT - Anthony Stone: attachment set

/run/user/1013/xpra/:1.log again


Mon, 20 Jan 2020 11:16:28 GMT - Anthony Stone:

The problem has been very troublesome today, so I have attached the log for today's session so far.


Mon, 20 Jan 2020 12:41:46 GMT - Antoine Martin:

I haven't been able to work out what might be using the clipboard excessively.

In this new log sample, the clipboard isn't used much. Maybe it isn't the clipboard that's causing the problem after all. Unless the clipboard problem is client side only of course, as this log is server side only.

The slow update behaviour was apparent during these edits.

How slow was it? Still a few seconds? If you can reproduce it again, please attach the xpra info output.


Mon, 20 Jan 2020 13:33:25 GMT - Anthony Stone: attachment set

xpra info output


Mon, 20 Jan 2020 17:53:03 GMT - Antoine Martin:

Thanks for the output. Now, that's a lot more interesting! I see that you have 7 virtual desktops?

client.desktops=7

And that your windows are / were on workspace 5:

windows.1.client-properties.2e49ad85051939e1692fc69f2d4268b5cbdd0733.workspace=5
windows.1.workspace=65535
windows.2.client-properties.2e49ad85051939e1692fc69f2d4268b5cbdd0733.workspace=5
windows.2.workspace=65535
windows.29.client-properties.2e49ad85051939e1692fc69f2d4268b5cbdd0733.workspace=5
windows.29.workspace=65535
windows.35.client-properties.2e49ad85051939e1692fc69f2d4268b5cbdd0733.workspace=5
windows.35.workspace=65535

If you are using virtual desktops and moving around them, try running xpra with:

XPRA_SET_WORKSPACE=0 xpra attach ...

We have had issues with that feature in the past.


The first window (Gnome-terminal) must have been fine, all the statistics look good:

client.window.1.batch.actual_delays.max=19
client.window.1.encoding.quality.cur=99
client.window.1.encoding.speed.cur=32

Though it is using a transparent encoding (that's gnome-terminal's fault - not xpra's):

client.window.1.encoding.selection=transparent_encoding

And because of the high performance, it chooses rgb32+lz4 which isn't very efficient, but probably OK.

The second one (emacs) looks like the one that is having problems, the batch delay is OK-ish:

client.window.2.batch.actual_delays.max=101

But the latency is not good:

client.window.2.damage.in_latency.cur=216

It has used a video encoding (h264) and av-sync is enabled:

client.window.2.total_pixels.h264=379399032
client.window.29.av-sync.enabled=True

Similar thing with window 29 and 35 (both xxdiff).

So, the first thing we can do is to make sure that we never use video mode for emacs or xxdiff: r25013 (you can easily apply this by hand to your installation by adding these entries to /usr/share/xpra/content-type/50_class.conf and restarting your server), no matter how poorly they redraw their window. (something we have seen before: #670). Alternatively, you can start your server with --video-encoders=none --av-sync=no, this will disable both video mode and av-sync.

If none of those things help, you may want to enable paint debugging to see which parts of the window are being repainted and when, maybe this will help:

XPRA_OPENGL_PAINT_BOX=1 xpra attach ..

The meaning of the colours shown is defined here: browser/xpra/trunk/src/xpra/client/paint_colors.py.

Found another ticket with a similar issue, but closed as "fixed": #1921.


Thu, 23 Jan 2020 14:26:09 GMT - Anthony Stone: status changed; resolution set

Thanks for the suggestions -- setting class-instance:emacs=text seems to have fixed the problem.


Sat, 23 Jan 2021 05:54:10 GMT - migration script:

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