Bug 411196 - Gwenview very slow to launch while the top item in the system clipboard was sent by KDE Connect using the shared clipboard feature
Summary: Gwenview very slow to launch while the top item in the system clipboard was s...
Status: RESOLVED FIXED
Alias: None
Product: gwenview
Classification: Unclassified
Component: general (show other bugs)
Version: 20.04.3
Platform: Kubuntu Packages Linux
: NOR major with 74 votes (vote)
Target Milestone: ---
Assignee: Gwenview Bugs
URL:
Keywords:
: 417847 419630 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-08-23 06:03 UTC by Mikel Pérez
Modified: 2021-07-03 09:54 UTC (History)
25 users (show)

See Also:
Latest Commit:
Version Fixed In: 20.04.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mikel Pérez 2019-08-23 06:03:55 UTC
SUMMARY
gwenview just recently became super slow to launch, upwards to 1 minute.
I tried executing it from the terminal to see if there was output to stderr, but nothing, it just created its window and I dragged the window and it kept the contents of what was behind its original position for like one minute then showed Recent Folders.
if I open a picture which launches it, gwenview's window appears after it's ready but is equally slow

STEPS TO REPRODUCE
1. open pic or launch gwenview
2. wait
3. see your pic

OBSERVED RESULT
super slow loading

EXPECTED RESULT
instant launch

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Fedora 30
KDE Plasma Version: 5.15.5
KDE Frameworks Version: 5.59.0
Qt Version: 5.12.4
Comment 1 Kai Uwe Broulik 2019-08-23 08:17:43 UTC
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?
Comment 2 Nate Graham 2019-08-23 18:45:57 UTC
FWIW there was some perf work done in 19.08, not sure if that would fix it.
Comment 3 Kai Uwe Broulik 2019-08-26 06:43:57 UTC
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.
Comment 4 emg81 2019-11-26 15:16:39 UTC
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).
Comment 5 Mark Smith 2019-12-11 20:43:00 UTC
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
Comment 6 kramski 2019-12-17 21:28:39 UTC
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
Comment 7 Torsten Römer 2019-12-18 19:27:06 UTC
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.
Comment 8 Doug 2020-01-14 22:14:48 UTC
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
Comment 9 darktori 2020-01-16 10:34:59 UTC
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.
Comment 10 Torsten Römer 2020-01-18 18:47:44 UTC
@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.
Comment 11 Matthias Mueller 2020-01-21 19:07:13 UTC
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
Comment 12 Vic Venti 2020-01-28 11:38:22 UTC
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
Comment 13 tagwerk19 2020-02-02 11:25:27 UTC
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
Comment 14 Duns 2020-02-04 20:07:48 UTC
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
Comment 15 Alex Fliker 2020-02-08 11:27:10 UTC
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.
Comment 16 Nate Graham 2020-02-14 23:35:27 UTC
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?
Comment 17 tagwerk19 2020-02-16 00:25:27 UTC
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
Comment 18 tagwerk19 2020-02-18 22:49:56 UTC
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.
Comment 19 Nate Graham 2020-02-18 22:51:11 UTC
*** Bug 417847 has been marked as a duplicate of this bug. ***
Comment 20 tagwerk19 2020-02-20 10:57:31 UTC
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-/
Comment 21 medin 2020-02-20 11:11:41 UTC
It's even slow to show svg images especially when zooming int/out. Mate viewer was much faster for me in the past.
Comment 22 tagwerk19 2020-02-22 14:32:13 UTC
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
Comment 23 Mark Smith 2020-02-28 19:57:12 UTC
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.
Comment 24 Nate Graham 2020-03-16 17:33:58 UTC
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
Comment 25 djusee 2020-04-10 09:31:11 UTC
*** Bug 419630 has been marked as a duplicate of this bug. ***
Comment 26 Torsten Römer 2020-05-02 16:55:13 UTC
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.
Comment 27 Nate Graham 2020-05-02 16:59:47 UTC
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.
Comment 28 Ewald Müller 2021-07-03 09:54:35 UTC
(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