Bug 442876

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.