xpra icon
Bug tracker and wiki

#2545 closed defect (fixed)

Slow update when editing

Reported by: Anthony Stone Owned by: Anthony Stone
Priority: minor Milestone: 4.0
Component: keyboard Version: 3.0.x
Keywords: Cc:

Description

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.

Attachments (4)

xpra.bug-report.zip (17.8 KB) - added by Anthony Stone 11 months ago.
bug report
xpra-remote.log (1.3 MB) - added by Anthony Stone 11 months ago.
/run/user/1013/xpra/:1.log
xpra-remote.log2 (908.5 KB) - added by Anthony Stone 11 months ago.
/run/user/1013/xpra/:1.log again
xpra.info (378.3 KB) - added by Anthony Stone 11 months ago.
xpra info output

Change History (12)

Changed 11 months ago by Anthony Stone

Attachment: xpra.bug-report.zip added

bug report

comment:1 Changed 11 months ago by Antoine Martin

Owner: changed from Antoine Martin to Anthony Stone

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?

comment:2 Changed 11 months ago by Anthony Stone

No, disabling the clipboard doesn't fix it.

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

comment:3 Changed 11 months ago by 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.

Changed 11 months ago by Anthony Stone

Attachment: xpra-remote.log added

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

comment:4 Changed 11 months ago by 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.

Changed 11 months ago by Anthony Stone

Attachment: xpra-remote.log2 added

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

comment:5 Changed 11 months ago by Anthony Stone

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

comment:6 Changed 11 months ago by 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.

Changed 11 months ago by Anthony Stone

Attachment: xpra.info added

xpra info output

comment:7 Changed 11 months ago by 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.

comment:8 Changed 10 months ago by Anthony Stone

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.