Bug 411196

I've observed the same but couldn't pinpoint to why it starteda happening. I have seen it block in QXcbClipboard, so maybe that is a Qt regression somewhere?

FWIW there was some perf work done in 19.08, not sure if that would fix it.

My suspicision is, if youc lick on an image in Dolphin, Gwenview starts, reads the clipboard (thorugh KIO::pasteActionText()) which then asks X for the clipboard. X then asks the application holding the clipboard, which might be Dolphin in this case, but Dolphin is stuck waiting on Gwenview to launch, and then you get a deadlock.
Haven't really investigated and the statement could be wrong, but it sure looks like it. When I launch Gwenview a second time then it's usually fine, and also when I copy something else into clipboard from another application.
I just don't understand how that could have regressed.

I have the same issue (same symptoms, at least), they started to bother me a while ago.

Gwenview 19.08.3 
Plasma 5.17.3
Frameworks 5.64.0
Qt 5.13.2
OS - Gentoo ~amd64

When I try to open image using terminal, I get no errors of any kind and same delay.
Tried to remove .config/gwenviewrc and .config/org.kde.gwenviewrc, hovewer that does not seem to help.

There is no process according to htop or system monitor that could have caused such delay.
I have OSes installed on SATA SSD and NVMe PCI-e SSD, so slow i/o shouldn't be an issue.

So far I couldn't see the pattern for this behavior, all those delays happen occasionally and randomly. 

Considering what Kai Uwe Broulik said, a possible quick and dirty fix would be setting lower value for "deadlock timeout" (or how they call it).

I have the same issue after the latest system update on KDE Neon. Gwenview takes forever to start, either from launching it normally or by double clicking a picture. Version is 19.08.3. Downgrading to 19.08.2 fixed it.

sudo apt-get install gwenview=4:19.08.2-0xneon+18.04+bionic+build37

This (randomly) started to hit me after upgrading to Gwenview 19.12.0 on Arch Linux.

KDE Frameworks 5.64.0
Qt 5.13.2 (built against 5.13.2)
The xcb windowing system

I have the same problem for quite a while now, since kubuntu 19.04 I think. Even Dolphin was slow displaying contents of folders with somewhat the same delay as Gwenview showing up.
Just did a clean new install of 19.10 including fresh home directory - still the same problem with Gwenview, Dolphin however seems to work fine again.

I have started having the same problem just recently:

KDE Neon: 5.17.5
KDE Frameworks:5.66.0
QT: 5.13.2
Kernel: 4.15.0-74 generic 
Gwenview: 19.12.1

I recently had this extremely slow startup issue. I'm using a SSD, and most applications open instantly. But gwenview took ~15 seconds showing a corrupted frame instead, no matter if opened by double clicking a picture in Dolphin or opening the program directly.

BUT! After I opened my clipboard manager and removed all my clipboard history from there, gwenview started to open up instantly again! I'm currently trying to reproduce the issue, but I don't know what exactly in the clipboard caused this, if that even was the reason.

@darktori@gmail.com, what you experience is what Kai Uwe Broulik described in detail in comment #3.

I can confirm that too. Just paste some text into the clipboard and the issue is gone - until another image finds its way in there.

I can confirm that clearing the clipboard yielded a fast start again.

Gwenview 19.12.1
Betriebssystem: Manjaro Linux 
KDE-Plasma-Version: 5.17.5
KDE-Frameworks-Version: 5.66.0
Qt-Version: 5.14.0
Kernel-Version: 5.4.13-2-MANJARO

probably not particularly helpful, but i can also confirm the gwenview/clipboard behavior

Gwenview: 19.12.1
Operating System: KDE neon 5.17
KDE Plasma Version: 5.17.5
KDE Frameworks Version: 5.66.0
Qt Version: 5.13.2
Kernel Version: 4.15.0-76-generic

Seen similar behaviour with Dolphin, see bug 416937, occasional one minute delays to Dolphin starting. 

Attached straces of Gwenview and Dolphin "slow starts" to bug 416937

Seen on newly installed KVM guest:

    Dolphin 19.12.1
    Gwenview 19.12.1
    from Neon 5.17

    KDE Plasma 5.17.5
    KDE Frameworks 5.66.0
    Qt 5.13.2

Yes, I have the same problem. But it's a problem only if I open a image from a symlinked folder. If I launch Gwenview to read an image from a non-symlinked folder it starts normally, fast.
But in my opinion there is something that developers should fix.
Thank you

Suffering from the same issue. The interesting thing is that after some time this issues solves itself. My main theory - kdeconnect has something to do with it. And considering that kdeconnect is sharing clipboard between the system and the smartphone there might be something to it.

I share your suspicion that KDE Connect has something to do with it. IN fact, I can confirm it!

I just copied a URL to an image on my phone, grabbed it off the synced clipboard on my computer, downloaded the image, and opened it in Gwenview, which hung. While it was still hung, I opened the klipper applet in the system tray and deleted the clipboard entry for the URL. Immediately Gwenview sprang to life.

I was not able to reproduce the issue by adding that same URL to the clipboard on the host machine, but I then reproduced the issue by copying any other text on my phone (not even a URL, just ordinary text) while using a synced clipboard. As long as the top item in the host clipboard came from KDE Connect, Gwenview hung on launch. The moment I deleted the KDEConnect-originated issue, Gwenview launched instantly.

KDE Connect folks (CC'd), any ideas?

A handful of observations:

Sporadic one minute delays launching Dolphin and Gwenview (as detailed in Bug 416937), but also noticed slowness when using Klipper. Test environment updated to:

    Dolphin 19.12.2
    Gwenview 19.12.2
    From Neon Testing

    KDE Plasma 5.18.0
    KDE Frameworks 5.68.0
    QT 5.14.1 

There were items in the Clipboard and gwenview 'started' after the clipboard was cleared (text and images were removed, the last item was text and gwenview started when that was deleted)

In these tests the kdeconnectd process was NOT running, however there were Clipboard items shared from the KVM

Some anecdotal evidence here, in a configuration with a KVM host running two guest systems (host system Fedora 30, KDE spin; guests Neon 5.18 and Neon Testing). Guest systems don't have KDE connect installed but show the same behaviour as seen with KDE Connect.

Launching Gwenview on the guest systems, it seems that they are sensitive to items being added to the clipboard 'copied' on the host. Items 'copied' on the host (being visible in Klipper) are copied across to the guest systems clipboard(s).
On the guests, you get that occasional 60 second delay opening Gwenview, with multiple ETIMEDOUT's in the strace. Closing gwenview can also hang.

Seen this with a 'copy' to the clipboard on the host affecting the behaviour of _both_ guest systems (!)

Quite often Klipper is frozen at the same time as Gwenview. However, in cases where it's possible to clear the clipboard, the delay stops (with no more ETIMEDOUT's logged) and Gwenview starts up again.

*** Bug 417847 has been marked as a duplicate of this bug. ***

A side issue; maybe an opportunity for confusion...

If you open an image in Gwenview, you occasionally get a delay and it is possible to see 'ETIMEDOUT' errors in an strace

    If you set up a test folder with several images, you may see instances where there are two ETIMEDOUT errors. This is not predictable but not uncommon.

    If you set up a folder with just a single image, you do not see these instances.

In either case it is possible to get the 60 sec delay (seemingly related to copying to the clipboard)

This seems not to matter if the image is in a symlinked folder or not.

I think this does not affect normal operation but it might be a "gotcha" as when setting up a test environment as you may only have put a single file in the folder 8-/

It's even slow to show svg images especially when zooming int/out. Mate viewer was much faster for me in the past.

Further to comment #18

Re: Issues in KVM guests when something is copied to the clipboard in the host. There seems to be an issue synchronising the clipboard between the host and guest systems, sketched out here:

    https://bugs.kde.org/show_bug.cgi?id=417590#c19

when the host is running Fedora 30 (an older or mismatched version?). The version of Klipper here 5.15.2

Have not seen the same problems when running the VM's under Fedora 31, Klipper 5.17.5

The version running in the guest; Neon Testing, Klipper 5.18.1

My bug was marked as duplicate of this. It appears it's indeed the same exact issue. I use KDE Neon on a physical computer. The issue is definitely caused by KDE Connect, which I also use. I had GV start slowly as described, disabled the clipboard feature, and it became instantaneous to launch again. Shame because the clipboard feature is pretty useful sometimes.

Git commit cf4ce0083b50e6ec4b0a60e3a8f2ec9f1b5ce01c by Nate Graham, on behalf of Tomasz Meresiński.
Committed on 16/03/2020 at 17:33.
Pushed by ngraham into branch 'release/20.04'.

Setup paste action text before main loop starts

Summary:
KIO::pasteActionText sometimes hang when called after main loop start.

Test Plan:
1. Setup KDE Connect clipboard sync
2. Copy something on the phone
3. Open gwenview. Without the patch it will start about 15 seconds

Reviewers: #gwenview

Subscribers: #gwenview

Tags: #gwenview

Differential Revision: https://phabricator.kde.org/D28051

M  +1    -1    app/fileopscontextmanageritem.cpp

https://commits.kde.org/gwenview/cf4ce0083b50e6ec4b0a60e3a8f2ec9f1b5ce01c

*** Bug 419630 has been marked as a duplicate of this bug. ***

Is this fix included in the current 20.04 release? I updated from 19.10 yesterday and now, after sending some photos with KDE Connect from my phone to the PC, Gwenview starts immediately (difference to 19.10) but just the window comes up and immediately freezes. After about 15 seconds it becomes responsive and shows the picture.

This can be repeated again and again.

After copying some text to the clipboard, Gwenview starts immediately and displays the image.

The fix is in *Gwenview* 20.04. If you're using *Kubuntu* 20.04, it somewhat confusingly ships with version *19.12* of KDE applications (which includes gwenview), not version 20.04. You would need to ask the Kubuntu people to backport this fix to the 19.12 version they ship.

(In reply to darktori from comment #9)
> I recently had this extremely slow startup issue. I'm using a SSD, and most
> applications open instantly. But gwenview took ~15 seconds showing a
> corrupted frame instead, no matter if opened by double clicking a picture in
> Dolphin or opening the program directly.

I've the same issue here under 
  Kubuntu 20.04.3 LTS, 
  Plasme 5.18.5,
  KDE-Frameworks 5.68.0
  Qt 5.12.8
  Kernel 5.4.0-77-generic
  64-bit


> BUT! After I opened my clipboard manager and removed all my clipboard
> history from there, gwenview started to open up instantly again! I'm
> currently trying to reproduce the issue, but I don't know what exactly in
> the clipboard caused this, if that even was the reason.

This resolved also my problem