https://bugs.kde.org/show_bug.cgi?id=526858
Bug ID: 526858
Summary: Recent Folders history entries on a slow filesystem
delay display of the requested image on startup
Classification: Applications
Product: gwenview
Version First 26.08.1
Reported In:
Platform: Fedora RPMs
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
When launched with an image path, Gwenview opens its window immediately but
does not paint the image until it has stat()ed the folders in its Recent
Folders history. If some of those folders are on a slow filesystem, the image
is delayed by the sum of the stat times. This is a delay, not a hang, and the
mount is reachable.
In my case the slow folders are on a FUSE mount, where each stat takes about 2
seconds. FUSE mounts appear as ordinary local paths, so they are not recognized
as remote. A 560 KB JPEG in a local directory takes over 8 seconds to appear.
This was identified in bug 393735 (comments 9 and 16), which was closed because
the reporter's cause was a dead NAS. Comment 9 there suggests the checks "can
be avoided or done in the background, to prioritize opening of the image
itself". That has not been done. It is also related to bug 272361. I don't know
which call is responsible. Comment 23 of 272361 shows
Gwenview::UrlUtils::urlIsFastLocalFile() calling
KMountPoint::List::findByPath(), but I'm not sure whether my stall is in the
same call.
Reproducing:
1. Have several folders on a slow but working FUSE mount in the Recent Folders
history.
2. Run "gwenview some.jpg" on a file in a local directory.
Result:
The window appears immediately but is blank. The image is painted only after
the stat calls finish, about 8 seconds later.
real 0m8.455s / user 0m0.272s / sys 0m0.104s
strace -f -T shows four newfstatat() calls on FUSE-mounted directories taking
1.8 to 2.4 seconds each, on the main thread, right after
~/.local/share/gwenview/recentfolders/gvhistory* is read.
Deleting the contents of ~/.local/share/gwenview/recentfolders/ brings startups
to the expected timeframe of ~<1s.
Expected result
The requested image is painted without waiting on the history. Any existence
check on history entries should be lazy or asynchronous, and probably should
not run on the UI thread.
SOFTWARE/OS VERSIONS
Gwenview: 26.08.1
KDE Frameworks: 6.30.0
Qt: 6.11.2
Operating System: Fedora Linux 44 (KDE Plasma Desktop Edition)
--
You are receiving this mail because:
You are watching all bug changes.
