SUMMARY Spectacle has become quite slow in taking screenshots, so that taking one of e.g. a specific frame of a video becomes quite difficult. STEPS TO REPRODUCE 1. Press the "print screen" key. OBSERVED RESULT There is a significant delay in taking the screenshot. EXPECTED RESULT The screenshot is taken immediately. SOFTWARE/OS VERSIONS Linux: KDE neon KDE Plasma Version: 5.22.5 KDE Frameworks Version: 5.86.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION
I tried setting desktop animation speed to "instant" and disabling compositing, but screen shots still have a painful delay after I press the keyboard shortcut. It was effectively instant when I used Xfce. This lag makes the KDE's screen shot feature mostly useless for gaming and video.
I measured the lag at about 1/3 of a second, which is a lot of lost frames. Method: Pressing Kronometer's Start key and Spectacle's Capture Active Window key at the same time. This was on an idle system with ~4 GHz CPU, an SSD, and both apps recently used (and therefore probably cached in RAM).
I also noticed this. In fact even simple things like displaying the version take alot of time and taking a screenshot a whopping 2s. LOG: $ time spectacle --version spectacle 23.04.0 spectacle --version 0,77s user 0,28s system 93% cpu 1,122 total # Take fullscreen screenshot in background to clipboard $ time spectacle -b -c -f spectacle -b -c -f 2,05s user 0,31s system 51% cpu 4,614 total SOFTWARE/OS VERSIONS Linux: EndeavourOS KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 Graphics Platform: Wayland
Note that this is still happening with KDE 6.
still happening on spectacle 24.07.70/kwin_X11 6.0.4 before the rectangular selection overlay pops up there is a 2s/3s delay after executing "spectacle -rpbc".
Same here, KDE/wayland. Spectacle has a delay oscillating between 1.2s to almost 3s. spectacle --version (takes 390ms to print the version) spectacle 23.08.5 plasmashell --version (takes 280ms to print the version) plasmashell 5.27.11 The fact that KDE executable take that long to print a simple version string is quite worrisome, though it doesn't explain the whole delay with spectacle, it is most likely compounding. With that said, this is a sad trend in software over the years (more lag and delays for no reason). The following examples are taken on power save mode (ie: battery power). When powered, it is usually 50% faster. Thinkpad T14 AMD gen2. xterm --help: 11ms alacritty --version (0.13.2): 8ms konsole --version (23.08.05): 270ms grep --version: 5ms ripgrep --version: 5ms kicad-cli --version (8.0.2): 240ms gnome-disks --help: 32ms kcalc --version (23.08.05): 250ms qalc --version (4.9.0): 19ms vlc --version (3.0.20): 17ms dragon --version (23.08.5): 250ms
All the KDE apps have that delay, interesting. I wonder if it's something deep in our platform code that would reault in all apps becoming slightly faster to launch if we fixed it.
it seems a lot more pronounced on older/slower systems on my t440p (quad-core, 2013) i have to wait up-to what feels like 5-ish seconds, while my desktop (5950x) takes around 400-600ms, and just `--version` taking ~200ms (both on plasma 5) biased to longer times if spectacle hasn't been launched in a bit
I did some profiling, but didn't spend time analyzing the results. So read with caution. It seems that most of the time was spent in fonts and opengl loading. So it might be a mix of system wide and kde specific performance issues. kde on wayland. versions: - xterm -v -> 3.8ms - alacritty --version -> 2.90ms - konsole --version -> 105ms /bin/true: - xterm -e /bin/true -> 39ms - alacritty -e /bin/true -> 150ms - konsole -e /bin/true -> 302ms KDE is twice as slow as alacritty, itself almost four times slower than xterm. I assume xterm is talking X via XWayland or something like that. As for `spectacle --version`, it takes 140ms on performance mode.
I started having this bug when I upgraded from Kubuntu 22.04 to 24.04. Using the print screen button makes my computer hang for about 15s, as does opening spectacle from the launcher. In "Configuration", I set "When launching spectacle" to "do not take a screenshot automatically" and that makes the app open quickly, but taking a screenshot still has a delay of a couple of seconds.
I must apologize: pressing PrtScr is instant. I have Shift+PrtScr mapped to "take a screenshot of a rectangular region", which is giving me a delay of about 15 seconds. The app is still 15s slow to open when it takes a screenshot of the whole desktop upon launch.
Please assign someone to this bug as it takes away the snappiness of the desktop. Compared to Gnome where the screenshot overlay appears instantly, on my system with an i5 8350u, the delay is significantly noticeable. The following are my system information: Operating System: Fedora Linux 40 KDE Plasma Version: 6.1.4 KDE Frameworks Version: 6.5.0 Qt Version: 6.7.2 Kernel Version: 6.10.10-200.fc40.x86_64 (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i5-8350U CPU @ 1.70GHz Memory: 7.5 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 Manufacturer: LENOVO Product Name: 20KES1E82S System Version: ThinkPad X280
It's a known issue that will be worked on when someone has the time to do so.
*** Bug 495514 has been marked as a duplicate of this bug. ***
kde in general seems inordinately affected by IO, but particularly spectacle the SSD in my laptop is capable of 200-300MB/s reads, but even a mere 30MB/s will have `spectacle --version` taking ~30s even on a NVME drive, this behaviour happens
(In reply to Nate Graham from comment #14) > *** Bug 495514 has been marked as a duplicate of this bug. *** Quoting from that bug: (In reply to Nate Graham from comment #3) > Yes, GNOME's tool is faster because it runs in-process; it's not a separate > app that needs to launch. So its code is always hot and ready for action, at > the cost of taking up more memory. I don't know the equivalent in Windows > works, though. > > Without re-architecting Spectacle and making the same trade-off, we likely > can't make it quite as fast. But hopefully we can come close. That's tracked > in Bug 442876; marking as a duplicate of it. I would say that that's not even the issue at play. I've just tried opening Spectacle and then selecting the rectangular region tool. It still takes ~2 seconds for Spectacle to capture the screenshot. It seems that there is a flaw (for lack of a better term) deep into Spectacle which makes it very slow, whether you use the system-wide shortcut or you try to capture screenshots when the program is already open and therefore (theoretically, at least) ready to run. I hope this can help narrow down the issue.