Open putzwasser opened 9 months ago
Thank you for reporting this. A couple of questions:
Thanks for your reply. Here's the info:
History Size=150
and Max cache file size=5MB
free -h
total used free shared buff/cache available
Mem: 15Gi 13Gi 978Mi 2.9Gi 4.0Gi 1.8Gi
Swap: 15Gi 63Mi 15Gi
https://unsplash.com/photos/a-view-of-a-snowy-mountain-range-at-sunset-ae__8IOF0Cs
Thanks! I can reproduce it.
Did this start happening recently or has this been happening since October?
I noticed it just recently. Couple of weeks, I guess.
The issue could be around longer though, because I update infrequently…
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?
So maybe you just need to disable then re-enable the extension?
Didn't help. Thanks for the suggestion, though :+1:
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.
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.
Yeah the lag seems to be related to large items (images, huge documents of text, etc)
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
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 🙂
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
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