Tudmotu / gnome-shell-extension-clipboard-indicator

The most popular clipboard manager for GNOME, with over 1M downloads
https://extensions.gnome.org/extension/779/clipboard-indicator/
MIT License
865 stars 166 forks source link

clipboard-indicator causes system lag on copy #428

Open putzwasser opened 9 months ago

putzwasser commented 9 months ago

After one of the last updates I noticed that clipboard-indicator causes a system lag when pressing CTRL + C.

Now every time I copy something the system hangs. How depends on the size of the "thing" (length of text, size of image, etc) added to the clipboard.

A JPG with one or two MB causes a hang for more than 1 second.

I had to turn the clipboard-indicator off, because of that.

Using manjaro (arch) + wayland

Tudmotu commented 9 months ago

Thank you for reporting this. A couple of questions:

  1. GNOME version?
  2. In the extension settings, what are the values for "History Size" and "Max cache file size"?
  3. How much RAM do you have on your system?
  4. Can you please share an image that when copied causes the lag?
putzwasser commented 9 months ago

Thanks for your reply. Here's the info:

  1. GNOME Shell 45.2 / 5.15.143-1-MANJARO
  2. History Size=150 and Max cache file size=5MB
  3. RAM
free -h
               total        used        free      shared  buff/cache   available
Mem:            15Gi        13Gi       978Mi       2.9Gi       4.0Gi       1.8Gi
Swap:           15Gi        63Mi        15Gi
  1. You can use any image you want. Keep in mind that this also happens with text, but on a smaller (but still noticeable) scale.

https://unsplash.com/photos/a-view-of-a-snowy-mountain-range-at-sunset-ae__8IOF0Cs

Tudmotu commented 9 months ago

Thanks! I can reproduce it.

Did this start happening recently or has this been happening since October?

putzwasser commented 9 months ago

I noticed it just recently. Couple of weeks, I guess.

The issue could be around longer though, because I update infrequently…

FlynnD273 commented 8 months ago

I had the same issue, but now I can't seem to replicate it. I ended up disabling the extension because I was trying out this rewrite in the hopes that it wouldn't have lag (it didn't, but it also doesn't preview images in my clipboard). When I re-enabled this extension, my lag was gone. I don't know if it'll come back eventually, but I wrote a script to copy number 1-1000 and it still doesn't seem to have any kind of lag. So maybe you just need to disable then re-enable the extension?

putzwasser commented 8 months ago

So maybe you just need to disable then re-enable the extension?

Didn't help. Thanks for the suggestion, though :+1:

Tudmotu commented 8 months ago

I am pretty sure it's an actual issue and will not be solved by re-enabling the extension. For me, copying the image provided by @putzwasser consistently reproduces the issue.

FlynnD273 commented 8 months ago

Interesting. For me, (GNOME 45.1, Ubuntu 23.10, 8GB RAM, with the same extension settings) I see lag when I copy the image, but if I try to copy anything else, I see no lag. I have no idea what I did to fix the problem though. I originally came across this issue because I had the same problem.

Tudmotu commented 8 months ago

Yeah the lag seems to be related to large items (images, huge documents of text, etc)

louisremi commented 6 months ago

I'm having the same issue when many images are in the clipboard history of clipboard-indicator: any new copy, even a small text, results in a ~1s long freeze of the system, as if clipboard-indicator was re-writing the entire content of my history on the drive in a synchronous operation. Clearing all images in the history of clipboard-indicator solves the problem

Tudmotu commented 6 months ago

I hope this issue will be fixed in GNOME 46 following this MR I opened on Mutter repo: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3551

I believe the lag comes from loading these large images to memory in the GNOME-Shell process. The MR I opened on Mutter will change this to use unix temp files so I hope it'll work better.

If there is anyone who can use the latest GNOME 46 nightly release to test it out, that would be great 🙂

road2react commented 2 months ago

Issue still occurs on GNOME 46, the lag can be traced to here:

== Stack trace for context 0x5dad28d70a10 ==
#0   7ffd9d583de0 b   file:///home/user/.local/share/gnome-shell/extensions/clipboard-indicator@tudmotu.com/registry.js:153 (3bf3788df100 @ 42)
#1   7ffd9d5844c0 b   file:///home/user/.local/share/gnome-shell/extensions/clipboard-indicator@tudmotu.com/registry.js:134 (3bf3788df060 @ 26)
#2   5dad28e3ceb8 i   file:///home/user/.local/share/gnome-shell/extensions/clipboard-indicator@tudmotu.com/registry.js:143 (3bf3788df0b0 @ 140)
#3   7ffd9d584fa0 b   file:///home/user/.local/share/gnome-shell/extensions/clipboard-indicator@tudmotu.com/extension.js:394 (3bf3788db060 @ 176)
#4   7ffd9d585690 b   file:///home/user/.local/share/gnome-shell/extensions/clipboard-indicator@tudmotu.com/extension.js:468 (3bf3788db1a0 @ 254)
#5   7ffd9d585da0 b   file:///home/user/.local/share/gnome-shell/extensions/clipboard-indicator@tudmotu.com/extension.js:299 (17843b4fcd80 @ 15)

It appears to be recalculating the hash for every image