flameshot icon indicating copy to clipboard operation
flameshot copied to clipboard

Very slow GUI start after flameshot is executed

Open kurobeats opened this issue 3 years ago • 16 comments

Same issue as discussed in https://github.com/flameshot-org/flameshot/issues/703

$ flameshot -v     
Flameshot v0.10.1
Compiled with Qt 5.15.2
$ echo $XDG_SESSION_TYPE
wayland

Same as discussed in Issue #703, when executing flameshot gui the command returns immediately so using time is pointless, it takes between 2 and 3 seconds to actually show the gui, additionally, flameshot config displays the config ui immediately.

Just retested in X11, issue does not exist. I recommend if any doubt exists from the development team, spin up a Fedora install in virtualbox or similar and verify.

OS: Fedora 34

kurobeats avatar Oct 11 '21 10:10 kurobeats

the command returns immediately

This is because the flameshot gui or any other subcommand just make a DBus call (send a request to the Flameshot daemon) to perform a specific action.

it takes between 2 and 3 seconds to actually show the gui

Can you check if it has elevated CPU usage using those few seconds? For example you can use programs that shows the historical graph of your CPU load (e.g nmon, bottom)

OS: Fedora 34

Also please specify how you have installed flameshot (dnf, Snap, Flatpak, AppImage, compiled it yourself, ...)

mmahmoudian avatar Oct 11 '21 11:10 mmahmoudian

I'm not seeing any spikes and to answer your other question, straight from the fedora repos sudo dnf install flameshot

kurobeats avatar Oct 11 '21 12:10 kurobeats

Using Flameshot v0.10.1 (0e43d4b3) on X11 KDE Plasma dual monitor (info below) I tried clicking on the tray icon and canceling the screenshot every time the overlay appears. In some runs it is instant and in some it might take up to roughly 2 seconds. I didn't see any spikes in RAM or CPU usage the process with the highest CPU usage was kwin_x11 and Xorg with CPU usage around 0.6%

System:
  Host: precisiontower Kernel: 5.10.70-1-MANJARO x86_64 bits: 64 
  Desktop: KDE Plasma 5.22.5 Distro: Manjaro Linux 
Graphics:
  Device-1: Intel CometLake-S GT2 [UHD Graphics 630] driver: i915 v: kernel 
  Device-2: AMD Lexa XT [Radeon PRO WX 3200] driver: amdgpu v: kernel 
  Display: x11 server: X.Org 1.20.13 driver: loaded: amdgpu,ati,modesetting 
  resolution: 1: 1920x1080~60Hz 2: 1080x1920~60Hz 
  OpenGL: renderer: AMD Radeon Pro WX 3200 Series (POLARIS12 DRM 3.40.0 
  5.10.70-1-MANJARO LLVM 12.0.1) 
  v: 4.6 Mesa 21.2.3 

mmahmoudian avatar Oct 11 '21 12:10 mmahmoudian

Getting this issue with SwayWM on Arch Linux

Video (shows spike in CPU usage + delay): https://ttm.sh/e91.mp4

[I] twilight@andromeda-server in ⌁
╰─λ flameshot -v
Flameshot v0.10.1 (d253143b)
Compiled with Qt 5.15.2
[I] twilight@andromeda-server in ⌁
╰─λ echo $XDG_SESSION_TYPE
wayland

CPU: Ryzen 5 3600 GPU: AMD Radeon Pro WX2100

proudmuslim-dev avatar Dec 12 '21 19:12 proudmuslim-dev

Same issue here. pop_os 21.10 and X11. Installed with apt.

> flameshot -v
Flameshot v0.9.0
Compiled with Qt 5.15.2
> echo $XDG_SESSION_TYPE
x11

My machine is VM running in VMWare in Windows host.

This has been issue for at least year for me. Running flameshot gui has 5-6 second delay (got 2560x1440 + 5120x1440 px screens attached to this VM).

On my other machines it's instant.

My guess is that flameshot saves image to disk before showing up overlay, which takes lot of time. I could be wrong.

I had same type of an issue when I was playing with i3 lock screen + scrot.

When I took screenshot with scrot, IIRC it would save to screenshot to /tmp, which is normal disk and was very slow for some reason and had few second delay even on bare metal + nvme disk.

My solution was to save image to tmpfs (/dev/shm in my ubuntu/pop_os instances) instead of /tmp, so image would save to RAM instead of disk. This made sceenshot (+ blurrying) image almost instant with scrot.

Racle avatar Jan 04 '22 06:01 Racle

Can you try the flameshot v11 beta? It has some major performance improvements and doesn't use DBus when launching the GUI.

veracioux avatar Jan 04 '22 07:01 veracioux

Can you try the flameshot v11 beta? It has some major performance improvements and doesn't use DBus when launching the GUI.

Nope, same problem with v11.0.0.

Quick test with time also, pressed esc immediately when I got flameshot gui open.

> time flameshot gui
flameshot: info: Screenshot aborted.
flameshot gui  0,25s user 0,16s system 5% cpu 7,577 total

Racle avatar Jan 04 '22 07:01 Racle

My guess is that flameshot saves image to disk before showing up overlay, which takes lot of time. I could be wrong.

Yes, if you are using Wayland the image is saved to the disk. We cannot do anything about this because the only way to take a screenshot on gnome wayland is to use the XDG portal. The portal is what saves the image to the disk. https://github.com/flatpak/xdg-desktop-portal/blob/6241c5e8bfb60502ac3c7bc3babede22d35f3b1c/data/org.freedesktop.portal.Screenshot.xml#L30

borgmanJeremy avatar Jan 05 '22 14:01 borgmanJeremy

Yes, if you are using Wayland the image is saved to the disk.

I assume same thing goes for X11, which I use, and it have same delay. Pop_os 21.10 doesn't have wayland support yet.

If not, is there way to debug this behavior so it could be fixed for X11?

And I also have weird behavior on VM. Flameshot worked just fine earlier today, but now it just screenshots black screen. But that is unrelated to this ticket, but it might be related to the tool flameshot uses when taking screenshot in x11+gnome.

Racle avatar Jan 05 '22 15:01 Racle

Just to add, I tested gnome-screenshot (40.beta was installed by OS)

time gnome-screenshot
gnome-screenshot  1,05s user 0,10s system 50% cpu 2,306 total

It took screenshot of all my windows and wrote image to disk (2.5mb filesize). So flameshot does something extra to that as it takes 7 times longer to show image.

Racle avatar Jan 05 '22 15:01 Racle

If you are able to do more detailed debugging you can check out this thread for collecting performance data: https://github.com/flameshot-org/flameshot/issues/1901

borgmanJeremy avatar Jan 05 '22 15:01 borgmanJeremy

@borgmanJeremy don't know if this helps at all, but I got something out of flamegraph. I ran script (included in zip file) and waited till it was finished. Didn't touch anything on VM.

Here is result.zip

Racle avatar Jan 05 '22 16:01 Racle

$ time flameshot full flameshot full 0.65s user 0.06s system 55% cpu 1.285 total

% time flameshot gui flameshot gui 1.00s user 0.53s system 40% cpu 3.804 total

% echo $XDG_SESSION_DESKTOP sway

% echo $XDG_SESSION_TYPE wayland

% echo $XDG_SEAT seat0

akhiljalagam avatar Aug 05 '22 18:08 akhiljalagam

Hey, I'm using Manjaro KDE + Wayland (amdgpu). Installed from official repo. Flameshot v12.1.0 (-) Compiled with Qt 5.15.5

It looks that I don't have any delay set. Same behavior when I just run action "Take Screenshot" instead of shortcut. No CPU spike. I have dual monitor.

So I tested on X11 running it through Konsole I don't see any delay (running: flameshot gui), when pressing shortcut there is some small delay but I think it is ok and caused by something else.

When running on Wayland there is huge delay when run in Konsole. E.g.:

flameshot gui                                                                                                                                              4s
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()

So issue is with Wayland combination. Spectacle do not have such delay. Happy to help to debug.

gelldur avatar Aug 19 '23 08:08 gelldur

I'm running Arch Linux KDE Wayland and searched the web for this specific issue, and, to my luck I've found this thread. I can confirm I have the same issue. I have a keyboard binding that executes flameshot gui when pressing some key combination and it takes a visible amount of time to actually show the Flameshot GUI.

I've tested using

time flameshot gui

and pressing Esc immediately after the GUI pops up and it takes about 1,5-2 seconds. It's noticeable.

reloadedd avatar Sep 23 '23 19:09 reloadedd

Some people seem to solve this with:

apt install appmenu-registrar vala-panel-appmenu-common

Sources:

  • https://forums.linuxmint.com/viewtopic.php?t=367866
  • https://forums.linuxmint.com/viewtopic.php?t=373384

I'm on NixOS though and I'm unsure what the corresponding change would be there.

Ten0 avatar Apr 14 '24 16:04 Ten0