Selection is very slow in Chrome/Emacs when using the gnome-shell extension

[tsdh]

Since recently, when having GPaste with its gnome-shell extension enabled, selecting some text using the mouse has become unbearable slow. For example, when I press the left mouse button at the "Since" in the previous sentence and then move the mouse to the end of the sentence, it'll take about five to ten seconds until the sentence is marked. During that time, the gnome-shell process uses up one CPU core with 100%.

It seems it's a problem with the gnome-shell extension rather than with GPaste itself. When I disable the extension in the settings, selection is fast again. But of course, being able to select old selections with the extension's interface is the main point in using GPaste...

Oh, and I just noticed that it's depending on the application I'm selecting text in, too. In Gnome Terminal, Eclipse, Libre Office, and Firefox the selection is generally fast even with the extension enabled. In contrast, in Chrome and Emacs, I get the slowdowns described above. Sadly, those are the applications I'm using almost exclusively...

I'm using GPase 3.12.1 with gnome-shell 3.12.2 on an Arch GNU/Linux laptop.

[Keruspe]

Interresting issue, I personally do not use emacs nor chrome so I never encountered this. I just tried with chromium and couldn't reproduce. Do you have "Primary selection affects history" enabled?

[tsdh]

Marc-Antoine Perennou notifications@github.com writes:

Hi Marc,

Interresting issue, I personally do not use emacs nor chrome so I never encountered this. I just tried with chromium and couldn't reproduce. Do you have "Primary selection affects history" enabled?

Yes, I do. And when I disable that, selection is also fast in Chrome and Emacs. (But of course, I want that the primary selection is also tracked.)

Bye, Tassilo

[Keruspe]

Thanks for the confirmation, I'll dig into this area then to find out what's wrong

[Keruspe]

Can you trying applying this patch locally to your installed gnome-shell extension? https://github.com/Keruspe/GPaste/commit/36f125da600621a81b9765a22917667f1a88ace9 (don't forget to reload gnome-shell afterwards) It may fix your issue.

[tsdh]

Can you trying applying this patch locally to your installed gnome-shell extension? https://github.com/Keruspe/GPaste/commit/36f125da600621a81b9765a22917667f1a88ace9 (don't forget to reload gnome-shell afterwards)

Executing "gnome-shell --replace" should be fine, right?

It may fix your issue.

No, not really. Maybe it has improved a bit, but still selection in Chrome and Emacs is very slow.

[Keruspe]

So, if you disable primary to history it works fine. Do you suspect this comes from the extension or are you sure? (did you try with the extension disabled ?)

Btw, to restart the shell, you can just open Alt+F2 and then type r in it

[Keruspe]

Oh, and which size is your history?

[tsdh]

Yes, disabling "Primary selection affects history" cures the problem, but then gpaste is not of much use for me.

And yes, it seems the problem is in the gnome-shell extension. At least, during the selection with the extension enabled, the gnome-shell process eats up 100% of one CPU core. And when I disable the option "Enable the gnome-shell extension" in the settings, selections are fast again. Actually, just disabling "Track clipboard changes" is enough for the speedup.

My max history size is 255, max display history size is 80, max memory usage is 50MB.

By the way: I'm not a new GPaste user. I'm using it since several month with great success, and it used to work fine. That slowdown when selecting text in Chrome and Emacs is rather new, maybe 2 weeks old.

Looking at the Arch package site at https://aur.archlinux.org/packages/gpaste/ I'd say the problem could only be introduced by the update from 3.12.0 to 3.12.1.

And thanks for the shortcut. That's handy!

[Keruspe]

I'm pretty much sure I got what's going on, I have an idea on how to fix it, will give it a shot as soon as I can.

[tsdh]

In the meantime, I've upgraded to gpaste 3.12.2 but the issue still persists.

[Keruspe]

Yes, I have work in progress to hopefully fix this locally but didn't manage to gather enough time to properly finish it yet :/ To be more specific, the issue here is that chromium, emacs, and a few others thinks that it's a good idea to send "the selected content has changed" events on a time basis rather than when you're done with selecting, and the client part of GPaste handles this poorly since it's too eager and recomputes nearly everything for each changed. That's the part I'm fixing.

[tsdh]

I don't want to put pressure on you. It's fixed when it's fixed. ;-)

Thanks for the explanation. Is the Chrome/Emacs way wrong? I mean, does the X protocol specification define exactly when such events need to be fired?

[Keruspe]

The X specification is quite vague in various areas, but most X apps seem to emit this event when you release the button.

[lucabrunox]

I think the problem is https://github.com/Keruspe/GPaste/blob/d448e2e5646ddff3e94b8846749f25a379b98e37/src/libgpaste/core/gpaste-clipboard.c#L129 . For long text, that blocks the gmainloop until the whole text is retrieved, thus blocking the whole gnome-shell. Use request_contents instead with a callback.

Given that extensions do not run in a separate process, extensions must be mainloop friendly by always using asynchronous functions.

[Keruspe]

@lethalman noting this suggestion, will apply once I finished my rework. Still hadn't enough time to properly work on it, I'll try to get this done for a last 3.10 and 3.12 release by the time gnome 3.14 is released.

[lucabrunox]

@Keruspe thanks for your work, gpaste is great :-)

[DamienCassou]

I have exactly the same symptoms in Emacs, Pidgin and Gedit. I can not reproduce on Gnome Terminal, Firefox or LibreOffice.

[Keruspe]

If anyone wants to test, I just pushed a bunch of commits which will improve quite a bit this issue, I hope. next step is following @lethalman advice, and then release time will be coming.

[DamienCassou]

@Keruspe I don't see any change with these latest commits. I ran gpaste dr and even killed gpaste and restarted it with gpaste dr. I'm sure the daemon that is executing is the latest (I checked the path under pgrep -a. The system still freezes for a few seconds when selecting things in Emacs.

[Keruspe]

@DamienCassou Did you also update the extension and restarted gnome-shell ? What I did is implement a new dbus signal in the daemon and port the extension to it. If you only updated the daemon, it still works as it's backward compatible, but it's identical to before.

[DamienCassou]

@Keruspe how can I be sure I use the newest extension? How do I introspect dbus for example? I didn't do anything special about the extension, but I restarted gnome-shell (and the whole computer) several times.

[Keruspe]

@DamienCassou if you do alt+F2, then lg. In the window that opens, go to the extension tab, and click open source for GPaste. In item.js line 110 should be resetText: function() {. If you get _resetText somewhere instead of resetText, the extension is not up to date.

[DamienCassou]

@Keruspe On line 110 I see a definition of resetText. On line 122, I see a definition of _resetTextSize.

[Keruspe]

@DamienCassou So it's up to date. Let's see if making clipboard calls async solves this.

[Keruspe]

I just made all calls to the clipboard asynchronous, following @lethalman suggestions. Homefully it'll help. Anyway I'm going to release as is tomorrow. If the problem persists, I'll try to reproduce it on some computer since I can't seem to be able to do so on mine.

[DamienCassou]

I don't see any difference. I'm on commit 9b25d164cfbc2f19f6fd0908d3327da28fd6a4c1. I restarted gnome-shell.

[lucabrunox]

@DamienCassou maybe you have enabled some kind of auto-sync between primary and selection clipboard, or some particular configuration.

[DamienCassou]

@lethalman the only thing I found is that "Middle-click Paste" is activated in gnome tweak tool. In particular, I can't find anything related in configuration.nix. Do you have any idea where I could search?

[lucabrunox]

@DamienCassou I mean the gpaste settings.

[DamienCassou]

@lethalman related settings that reproduce the problem are:

Track clipboard changes --> on
Enable the gnome-shell extension --> on
Sync the daemon state with the extension's one --> on
Primary selection affects history --> on
Synchronize clipboard with primary selection --> off

[Keruspe]

I'm going to release 3.14 tomorrow and then I'll setup an installation to try to reproduce as hard as I can and I'll come back to you then.

[DamienCassou]

@Keruspe as far as I can tell, the bug is fixed in 3.12.3. Thank you very much.

[Keruspe]

@DamienCassou Cool, closing then. Feel free to reopen if anyone can reproduce it with latest releases.

[tsdh]

@DamienCassou @Keruspe Sorry for not being responsive for some weeks but I still have the issue with gpaste 3.12.3. It's possible that it got a bit faster but still far from being usable.

[DamienCassou]

I confirm the problem is still there but in less use cases.

[Keruspe]

3.14.1 will roll out in a few days and should further improve this.