Version: (using KDE 4.4.3) OS: Linux Installed from: Debian testing/unstable Packages If you have several entries in klipper (in my case it is set to max 80 entries) and you open the history (e.g. by ctrl+alt+v) the history window becomes very flickering when typing a text to filter for an entry. The window is redrawn very often und it takes quite long until the filtering process is finished. In most cases it is only approx. 1 second. But today it took so long that even the desktop effects became suspended. I am using activated effects with XRender nvidia 195.36.24 kernel 2.6.33 and 2.6.34 nVidia Corporation G72 [GeForce 7300 LE]
I have same problem especially when using two displays. When I try to filter on second screen it is better to kill klipper than waiting. This worked fine in kde3, klipper filter just worked as expected - no delay even with hundred entries. Doesn't matter if its opengl or xrender. Disabling effects doesn't help either. I also have nvidia card - GeForce 8400 and on second computer GeForce 8600
This still is reproducable in KDE 4.5.72 (4.6 >= 20101012) (compiled from trunk). There are way too many redraws of the klipper popupmenu when typing a character for filtering the content. Though the menu did become much faster and usable again. It does not take half a minute to be completely redrawn, but happens in about 1 second now. But anyway you can see the flickering. How to reproduce: Set klipper to allow e.g. 70 entries. Fill the clipboard history by marking different text snippets with the mouse. Now open the klipper popup and type a character (or two or three) to filter the content.
Same problem here. Also configure klipper takes a lot of time to appear. The problem seems to become more acute when using thin clients like VNC/NoMachine/Citrix The copy paste operation between them becomes a nightmare. Sometime works sometimes not. If I remember correctly in kde 4.3 was better. I also have 256 entries in klipper. I have reduced it to 64. Let's see the results
With installing KDE4.6.1 (from debian/experimental-snapshots) klipper became much faster. Filtering is now usable again. I think there ist still room for enhancement, as it still flickers and resizing of the window does not look smooth, but at least it is fast again. So a klipper developer might want to decide if he wants to close this report or keep it open for checking this some day.
See also bug 190022
*** Bug 190022 has been marked as a duplicate of this bug. ***
Created attachment 71546 [details] Patch to remove flicker Added patch which removes the flickering from klipper and also speeds things up a little. A next step would be to include a slight delay (e.g 400 ms) before the clipboard is searched. This gives a performance boost since klipper would not search with every keystroke. Please let me know if this is desirable. it is easy to implement (I already have a version and could submit it as another patch)
Created attachment 71547 [details] Screencast to show patch 71546 A screencast for the patch 71546. It shows the old implementation on the left and the new one on the right
Thank you for the enhancment, this really looks very promising. I do not know if the 400ms delay is required. Searching through such a small stack as given in klipper (in most cases max. 80-250 entries?) should be fast enough even if the search is done on each key stroke as long as there is no redraw bug. Also the question is how short the delay should be. Is 400ms too long so that it does feel slow again? If you implement the delay you should try out different time gaps. I think that 200-300ms should be a good value (from my experience with Ajax-web-GUIs). Gert
Created attachment 71559 [details] Patch which removes flicker and adds a delay before rebuilding the popup Added the timer delay to the patch. There was also a line missing in the last patch
Gert, Thanks for the comments. I played around with the delay, and 350 seemed to be the sweet spot. 300 would result in sometimes in updating before I was finished typing. I run klipper at 2048 entries. Running with the old implementation ( without forcing the size ) was unbarable and ugly. While it is not totally neccessary to do the delay, at the end, I think it might be beneficial for slower machines. Maybe we should only delay when the history exceeds a given amount?
Created attachment 71585 [details] Patch without the timer I have added another patch, without hte timer. I think you should try out both and see which one actually seems to feel better. Finally, I think it might be a smart to move the regex parsing to a background thread. inputting a complex regular expression causes my machine to freeze. But that would be a separate issue.
@Gert, Would it be possible to receive some feedback? While using klipper I found that depending on some configurations (e.g. clipboard contains long text and many entries (about 2k in my case) ) searching on every keypress is slow. Moreover, it stalls the UI thread, making it even hard to kill klipper at that point. As a temporary solution, we should try and use a delayed triggering. The value 300 feels alright without much of slugging behind. The ideal solution is to take out the computation into the background thread. Ill start on that. What do yo think?
Just to make sure: I am not a KDE developer, just a bug reporting user (having dev experience in perl, javascript, etc. mainly in the web area). So here are my 2 ct: "Maybe we should only delay when the history exceeds a given amount?" IMO one of the most important rules is: Try to keep it simple. If the 300ms delay does feel good, it should be applied without exceptions. If you change the behaviour depending on the number of entries, it will be harder to report or hunt bugs as there are different execution paths and the code is more complex. "Moreover, it stalls the UI thread, making it even hard to kill klipper at that point." Does this mean the whole KDE is freezing because klipper takes a break? Here the best solution would be to let run all plasmoid widgets (and other stuff? Is klipper a plasmoid?) in there own thread. Currently a crashing plasmoid may lead into a none starting KDE. So I am not sure if it makes sense to implement threading into each program like klipper? It does sound complicated. Also it might be more interesting to find and repair the reason of the stalling, instead to put it into a background thread that can stall? Testing the patch is a little bit complicated for me as my compilation test check out of kde trunk did not compile for months anymore. (I did not try again since january.) And currently it is hard to find the time for retrying it (as I had to start from scratch because of probably many new modules, dependencies and svn2git migrations, etc.). Gert
Also seeing the same issue with KDE 4.10 on opensuse 12.2. Delay can be up to 10-15 seconds at times.
(In reply to comment #12) > Created attachment 71585 [details] > Patch without the timer > > I have added another patch, without hte timer. I think you should try out > both and see which one actually seems to feel better. You should probably open a review request so it gets a chance of going in kde-workspace ;-)
hey awesome people ;-) I've been trying the patch that Wattos made, it works great. I've made a rebuild klipper on build.opensuse.org if anybody is interested in a RPM ;-) https://build.opensuse.org/package/show?package=kdebase4-workspace&project=home%3Ajospoortvliet%3Abranches%3AKDE%3ARelease%3A410 Wattos, I'm not sure if you ever managed to finish that putting the computation in the background... If you did I'd be happy to test the patch and make RPM's of it, too :D seriously, this has been bugging the heck out of me and I'm real glad to see there are patches to try out... Thanks!
Yes, please open a request at http://reviewboard.kde.org so this does not get lost. you can add plasma as a review group. I'm not sure (because I don't know klipper's code) why it is constantly rebuilding its popupmenu; would seem to make a lot more sense to just keep a datastructure around with the relevant data (i assume it does this already) and only when the popup menu is shown repopulate it (by connecting to the abuotToShow() signal). though, as i said, i don't know klipper's code at all, so perhaps it is using the popup as its data model and that is what is searches through? anyways, yes, this would be great to get in for 4.11.
Just checking - Wattos, you got this in, right? So this bug can be closed?
Ok, I just heard that openSUSE patches this in, that's why it works fine... Meh. On the other hand, I got that patch in (my first ever contribution to openSUSE packaging) so yay ;-) Still, I'd love to see all Klipper users benefit, not just the ones on openSUSE :D
(In reply to comment #21) > Ok, I just heard that openSUSE patches this in, that's why it works fine... > Meh. On the other hand, I got that patch in (my first ever contribution to > openSUSE packaging) so yay ;-) Hmm, then I'm not sure I'm hitting the same bug or it's still not fixed for me. Using openSUSE 13.1 and still having klipper (Ctrl-Alt-V) delays of up to a minute now. (Still waiting for it to appear as I type this). Happening around 10 times a day. Restarting klipper fixes it for a while.
The problem seems to occur most when interacting between Google Chrome/Chromium and e.g. konsole. It becomes especially bad if using e.g. Google Docs, and copying and pasting from e.g. a spreadsheet to konsole, via CTRL-C, Shift-INS. If I use CTRL-ATL-V to show the pasted content, it can take up to two minutes to show the klipper pop-up. Given that the other apps that were mentioned (VNC/NoMachine/Citrix) may also have some sort of clipboard sharing mechanism, could it be klippers interaction with that that causes the issue?
(In reply to Marcus Furlong from comment #23) > The problem seems to occur most when interacting between Google > Chrome/Chromium This sounds like bug #337961
Yes, that's the behavior I've seen! I wonder is it specific to chromium or are other apps also affected.
I cannot reproduce this anymore. Either it is fixed in KDE5. Or it depends on the graphics card/driver you are using. When reporting this issue I had an nVidia Corporation G72 [GeForce 7300 LE] card. Nowadays I am using intel graphics.
I use latest klipper from latest plasma 5.11.2 It is very very slow on search, when clipboard contains big text. Please help on getting klipper more fast and responsive
This bug is from KDE 4.4.3, not Plasma 5.15.3. This problem appears to be fixed because I could not reproduce it. It's unclear if Ural was referring to the applet in 5.11 or the popup menu, which is what this bug is about. If anyone has a similar issue, please test the newest version of Plasma and make a new bug report.