SUMMARY Desktop freezes for about 4-5 seconds after I take a screenshot and save the picture. There is no right click on the desktop and the task bar is unresponsive too. If I click on an item untill the system is frozen, it opens after it become responsive, hence it remembers the clicks. STEPS TO REPRODUCE 1. Take a screenshot and save it. OBSERVED RESULT The system freeze for 4-5 seconds. EXPECTED RESULT Responsive system. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux KDE Plasma Version: 5.19.4 KDE Frameworks Version: 5.73 Qt Version: 5.15.0 ADDITIONAL INFORMATION This problem appeared with Plasma 5.19.
Plasma 5.19.5 - the problem is still here. Can I get some attention please?
Just a clarification: The OS is on SSD and the screenshots taken too.
After a few updates the problem is still here.
KDE Frameworks Version: 5.75 - the problem is still here.
KDE Plasma 5.20 - the problem is still here. Please can someone help me?
I can only confirm it on my machine. But the freeze takes only 2 seconds, not 3-4. Does not happen when spectacle is launched in background without a gui.
Thanks for confirming. Let's hope someone look at this problem already.
Are you copying the image into the clipboard? If so does the freeze happen if you don't?
No, I save the picture to SSD as I mention it in one of my previous posts :)
I can confirm this. Same steps as @Nick Stefanov did and it freezes for 2-4 seconds (though cursor does move), and also can confirm @Antonio's workaround works. Thanks! Launched from a terminal, no message shows up until I hit the "Save as.." button. Then, these warnings: kf.kio.core: "Could not enter folder tags:/." kf.kio.widgets.kdirmodel: No node found for item that was just removed: QUrl("file:///tmp/somerandomfileofmine") libpng warning: iCCP: known incorrect sRGB profile kf.kio.widgets.kdirmodel: protocol mismatch: "" vs "file" Last line, the protocol mismatch one, repeats every 3-4 seconds even if I don't click "Save". After that, Spectacle closes normally. There is no high CPU usage, no visible time_wait (after all, I'm saving my screenshots into /tmp and that directory is a TMPFS) and, after doing a PERF (record and report), nothing relevant shows up there. System: Gentoo stable KDE Plasma Version: 5.19.5 KDE Frameworks Version: 5.74.0 Qt Version: 5.15.1 Spectacle Version: 20.04.3
I want to use the GUI though :) It would be nice the devs to look soon at this bug.
I started noticing this not long ago, large parts of my desktop would freeze every time I ran my screenshot script (which just calls `spectacle --activewindow --background --nonotify --pointer --output "$tempfile"` essentially) I bisected it to db944286edbdf91e79a06871d570bd01b7c595af, and indeed when running that commit my taskbar etc freezes for a few seconds. db944286edbdf91e79a06871d570bd01b7c595af is the first bad commit commit db944286edbdf91e79a06871d570bd01b7c595af Author: Antonio Prcela <antonio.prcela@gmail.com> Date: Tue Jun 9 23:23:08 2020 +0200 Improve settings logic and layout Rearrange setting so it's no more possible to have all three options activated at once: copy image to clipboard, save location to clipboard and autosave image. Added check to avoid having all three settings at once. Updated layout with some spacers. BUG: 420477 src/Gui/SettingsDialog/GeneralOptions.ui | 144 ++++++++++++++++---------- src/Gui/SettingsDialog/GeneralOptionsPage.cpp | 14 +++ src/Gui/SettingsDialog/GeneralOptionsPage.h | 2 + src/Gui/SettingsDialog/SaveOptions.ui | 71 +++++++++---- src/Gui/SettingsDialog/spectacle.kcfg | 10 +- src/SpectacleCore.cpp | 1 + 6 files changed, 164 insertions(+), 78 deletions(-)
To further clarify, the above testing was done with just running `spectacle --activewindow --background --nonotify --output ~/test.png` and seeing if system froze or not.
Good finding, thank you! For me it freeze with your command too.
(In reply to Magnus Boman from comment #12) > I started noticing this not long ago, large parts of my desktop would freeze > every time I ran my screenshot script (which just calls `spectacle > --activewindow --background --nonotify --pointer --output "$tempfile"` > essentially) > > I bisected it to db944286edbdf91e79a06871d570bd01b7c595af, and indeed when > running that commit my taskbar etc freezes for a few seconds. > > db944286edbdf91e79a06871d570bd01b7c595af is the first bad commit > commit db944286edbdf91e79a06871d570bd01b7c595af > Author: Antonio Prcela <antonio.prcela@gmail.com> > Date: Tue Jun 9 23:23:08 2020 +0200 > > Improve settings logic and layout > ... Just checked into that commit. Looks like I messed up while rebasing. https://invent.kde.org/graphics/spectacle/-/blob/master/src/SpectacleCore.cpp#L144 And two lines below is the exact same piece of code. Tho, with or without that commit, the desktop freezes for a brief moment. And, as mentioned earlier, only when a screenshot is taken while the Spectacle is running in GUI mode. With your command - running in Background/Dbus mode - it does not freeze the desktop.
For me it does freeze the desktop with running in Background/Dbus mode.
(In reply to Antonio from comment #15) > ... > Tho, with or without that commit, the desktop freezes for a brief moment. > And, as mentioned earlier, only when a screenshot is taken while the > Spectacle is running in GUI mode. > With your command - running in Background/Dbus mode - it does not freeze the > desktop. I only use Spectacle in background mode, as I primarily use it together with an uploading script. So if this were only in GUI I'd never noticed. For me going back to the commit before makes the desktop no longer freeze. However, that commit looks rather old and I only started noticing this bug for the last week or two at most.
(In reply to Magnus Boman from comment #17) > I only use Spectacle in background mode, as I primarily use it together with > an uploading script. So if this were only in GUI I'd never noticed. > > For me going back to the commit before makes the desktop no longer freeze. > However, that commit looks rather old and I only started noticing this bug > for the last week or two at most. One thing is confusing me, is that this Bug report has been made before that commit got merged :s (In reply to Nick Stefanov from comment #16) > For me it does freeze the desktop with running in Background/Dbus mode. Are both of you on Plasma 5.19.x and what version of Spectacle are you running? My System Info: Spectacle version 21.03.70 (build with latest git master). Operating System: Manjaro Linux KDE Plasma Version: 5.20.3 KDE Frameworks Version: 5.76.0 Qt Version: 5.15.1 Kernel Version: 5.8.18-1-MANJARO OS Type: 64-bit Processors: 8 × Intel® Core™ i7-4700MQ CPU @ 2.40GHz Memory: 15,3 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 4600
My info is in the first post. Given I'm on Arch I'm with the latest KDE Plasma now - 5.20.3.
(In reply to Antonio Prcela from comment #18) ... > Are both of you on Plasma 5.19.x and what version of Spectacle are you > running? > > > My System Info: > Spectacle version 21.03.70 (build with latest git master). > > Operating System: Manjaro Linux > KDE Plasma Version: 5.20.3 > KDE Frameworks Version: 5.76.0 > Qt Version: 5.15.1 > Kernel Version: 5.8.18-1-MANJARO > OS Type: 64-bit > Processors: 8 × Intel® Core™ i7-4700MQ CPU @ 2.40GHz > Memory: 15,3 GiB of RAM > Graphics Processor: Mesa DRI Intel® HD Graphics 4600 I'm on arch as well just like OP, tesing+KDE-Unstable repos. Only spectacle is on -git version right now (as far as KDE packages goes). Operating System: Arch Linux KDE Plasma Version: 5.20.3 KDE Frameworks Version: 5.76.0 Qt Version: 5.15.2 Kernel Version: 5.9.10-zen1-1-zen OS Type: 64-bit Processors: 16 × AMD Ryzen 7 3700X 8-Core Processor Memory: 15.6 GiB of RAM Graphics Processor: Radeon RX Vega
Plasma 5.20.4 - the bug is still here. Thank you :)
(In reply to Nick Stefanov from comment #21) > Plasma 5.20.4 - the bug is still here. Thank you :) I can also confirm. Will see if I find some time this week to analyze. Haven't forgotten about it :)
It would be great :)
KDE Plasma 5.20.5 - the problem is still here and it's annoying.
For what it's worth I tried spectacle both 20.12.1 and latest git and it seems to work fine now. KDE Plasma 5.20.90.
Nope, I'm with 20.12.1 and the problem is still here. I niticed another related problem, though - if I overwrite a .png, .jpg .etc file downloaded from the internet, Plasma again freezes in this manner.
Plasma 5.21 - the problem is still here :(
This bug still plague my life. Are there any news?
*** Bug 435123 has been marked as a duplicate of this bug. ***
it's sad it freezes for me with either -bn or separate -b, -n. It always freezes no matter what and my PC isn't form 2008 - i9900K, GTX 1080 with a SSD. Yes, I oserve this freeze on a SSD...
I just tried it with: "spectacle --activewindow --background --nonotify --output ~/test.png" and "spectacle -bn" No freeze of the desktop. Tried with the latest git build of Spectacle (21.07.70). BUT I have a similar issue with GnuCash. When I close it, it freezes both the taskbar AND desktop for about 3-4 seconds. No such bug reported on their bugtracker yet: https://bugs.gnucash.org/buglist.cgi?quicksearch=taskbar My system: Operating System: Manjaro Linux KDE Plasma Version: 5.21.5 KDE Frameworks Version: 5.82.0 Qt Version: 5.15.2 Kernel Version: 5.12.5-1-MANJARO OS Type: 64-bit Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 2700X Eight-Core Processor Memory: 15,6 GiB of RAM Graphics Processor: Radeon RX 570 Series
spectacle --activewindow --background --nonotify --output ~/test.png Freeze the desktop. spectacle -bn Same. I'm wondering how nobody of the devs isn't asked me for a details or something. Are they really that detached?
(In reply to Nick Stefanov from comment #32) > spectacle --activewindow --background --nonotify --output ~/test.png > > Freeze the desktop. > > spectacle -bn > > Same. > > I'm wondering how nobody of the devs isn't asked me for a details or > something. Are they really that detached? Detached? You do know that they do this in their free time? Maybe debugging with gdb would help to find the source of the problem. But my knowledge of gdb is very limited so I can't help you with that.
Yes I know but they could ask some details. Nothing. Like the care at all.
It's like they don't care at all*
I don't if it's been mentioned or if it would even be helpful, but I've noticed that while plasmashell is frozen the file and its thumbnail already exist, they either get generated at the start of the freeze or immediately before, so it's not like the freeze is waiting for the file to be created. I wonder if there's some security timeout/fallback somewhere that'd only trigger when using both -b and n flags. If you were to only use -b, spectacle's gui won't pop-up, but a notification will, and if you use -n the pop-up won't appear but the gui will. On the other hand using both will make spectacle completely "silent", maybe something checks that something is launched as a result of taking a screenshot?
Additionally, if spectacle's interface is already open in the background, using spectacle -bn will NOT result in a freeze.
Yes I can confirm - keeping Spectacle in the background and using -bn doesn't freeze the shell.
After some more testing (with the GUI closed) I noticed that: -bnc does NOT cause a freeze. -bnco does NOT cause a freeze either. -bno DOES cause a freeze.
I get the same result as yours. Thanks for testing.
Plasma 5.22 - The problem is still here.
Plasma 5.22.3 - The problem is still here.
Now I tried deepin-screenshot and gnome-sceenhot and there's no such problem. Would finally someone look at this annoyng problem?
Just tested with: spectacle -bno ~/test.png Can't reproduce it, nor on my host machine and neither in a Manjaro VM. Is the output drive the same as the host machine? Mine is set up like this: root partition and home partition on same drive, output to home partition. On VM it's all the same drive & partition. Do you maybe output to another drive?
My setup is the same, I never divide home from root. Source is in home. I found the culprit - Copy image to clipboard setting.
(In reply to Nick Stefanov from comment #45) > My setup is the same, I never divide home from root. Source is in home. I > found the culprit - Copy image to clipboard setting. Thanks, that should help. And I can reproduce it now. Can you test the following please: spectacle -ac Should take a screenshot of the active window and save it into the clipboard. It doesn't have much to do with this bug, but seems like -c ain't working properly anymore. Seems like copy to clipboard has a few bugs :(
(In reply to Antonio Prcela from comment #46) > (In reply to Nick Stefanov from comment #45) > > My setup is the same, I never divide home from root. Source is in home. I > > found the culprit - Copy image to clipboard setting. > > Thanks, that should help. And I can reproduce it now. > > Can you test the following please: spectacle -ac > Should take a screenshot of the active window and save it into the > clipboard. It doesn't have much to do with this bug, but seems like -c ain't > working properly anymore. Seems like copy to clipboard has a few bugs :( This one, while having the option set to "do not copy anything" in the general settings.
With spectacle -ac it's working fine but it takes screenshot of the whole screen :)
(In reply to Nick Stefanov from comment #48) > With spectacle -ac it's working fine but it takes screenshot of the whole > screen :) Ah, nvm, "-c" works only when used with "-b". And "-a" should take a screenshot of the active window, except when your "active window" is the desktop.
I see :)
(In reply to Nick Stefanov from comment #50) > I see :) So this line is causing the issue. If you comment it, the desktop doesn't freeze. https://invent.kde.org/graphics/spectacle/-/blob/master/src/ExportManager.cpp#L543 Leaving this here and doing some further analyzing. Tho I doubt that my knowledge of C++ will be enough to fix this :(
Thank you! Let's hope they'll fix it.
I'm no longer seeing freezes, can anyone confirm? No idea when it was fixed, but I'm currently using spectacle 21.12.1-1 Could anyone else confirm?
Yes, there's no problem now even with the option for copying to clipboard checked.