Thanks for the bug report! Unfortunately it reports multiple distinct issues, which will make it not actionable. See https://community.kde.org/Get_Involved/Issue_Reporting#Multiple_issues_in_a_single_Bugzilla_ticket for more explanation.

There are also multiple existing open issues related to speed in working with Gwenview, as listed below. If you have a distinct issue not covered by those, please feel free to open a bug report for that accordingly, with specific steps to reproduce.

https://bugs.kde.org/show_bug.cgi?id=406431
https://bugs.kde.org/show_bug.cgi?id=454206
https://bugs.kde.org/show_bug.cgi?id=369255

(And for Dolphin, as that was mentioned in the body of the description: https://bugs.kde.org/show_bug.cgi?id=306290 )

Thanks!

Hi John ..

thanks much for your input here but wait a minute please ... All your mentioned duplicates are about gwenview or dolphin managing and working with big folders but I specifically report that we have very poor performance while working with particular images in general so problem in here would be qt bindings on image formats library .. I do NOT report the issue related to huge folders .. I report very poor performance while opening particular files ...

Issue is 100% reproducible .. Just try for example opening (loading) a set of RAW files ... it will require about 4 times more resources and time while opening N raw files (I was testing that with Nikon RAW files) compared to other applications - I was testing Vs Gnome environment .. Opening JPGs seems slower to me also .. Generating thumbnails too ..

Please check again my original description .. I've spent time testing that Vs other applications or DEs (Gnome) .. My bugreport has nothing to do with working with huge folders but it is about our performance and effectivity while opening particular files which can be easily measured and benchmarked but just opening batch of files ..

Also I've mentioned my other bugreport opened in suse bugzilla - https://bugzilla.opensuse.org/show_bug.cgi?id=1230545 ... as you can see it is confirmed and Fabian says there

"I see the same issue on Tumbleweed, loading the linked raw images does indeed take ~10s each. By looking at the perf profile I saw that most of the time is spent within libraw, which looks correct. Some added logging output showed that the raw data was unpackaged three times and processed twice, which can be optimized."

I believe that we shall review the code how we're opening the images in general .. It is just very slow compared to others ... As mentioned multiple times - geeqie and JPGs 60seconds Vs gwenview/KDE same JPGs 2:28 and very same pattern with RAW files or generating thumbnails for a folder Vs Gnome ...

thanks and regards, ~dan

I'm sure you have a good intuitive sense of what you're experiencing there - I think the thing that would be needed here is specific, explicit steps to reproduce a distinct bug, which a bug triager could then follow and use to confirm an observed result that you're reporting.

Please see https://community.kde.org/Get_Involved/Issue_Reporting#Steps_to_Reproduce for an example of listing out those steps in an way that helps someone else reproduce behaviors on their own machine, so folks can walk through that process and then help with diagnosing.

Thanks,

Hi John,

it's very easy :) .. just open folder with images, ideally raw images or big out-of-camera JPGs (if you don't any I can provide some) and just traverse through them (in fullscreen mode) with arrows (eg typically right-arrow to jump to next image) .. and measure how long it takes traversing through whole folder ..

I verified with two different computers and two versions of Qt/gwenview that traversing through images (doesn't matter if JPG or RAW) is significantly slower in KDE with gwenview compared to Eye of Gnome or even compared to program like geequie (gtk based image browser similar to gwenview)

As I've outlined above, just a very rudimentary test ... Skipping through 50 raw images (with gen 13th i7 cpu, plenty of memory and fast m2 ssd drive - btw about same perf as usb 3.2 external USB disk so obviously the i/o on input is not the bottleneck here) took 2:08 seconds with gwenview (++ full cpu utilization while doing that) Vs 35 seconds with geeqie .. Which means that images in geeqie are loading about 4 times faster and requiring thus much fewer cpu resources ..

I did same test with JPGs for which I've used a 45MPx JPEGs from Nikon D850 .. I've been traversing with geeqie throu images in one folder on fullscreen and stopped after 60 seconds .. Then I've run same set of images with gwenview (just image on fullscreen and keep hitting Next) and the same set required incredible 2:28 ..

The speed ratios based on my tests are: JPGs 60:148 (seconds) and for RAWs 35:128

I was testing same in native Gnome DE also with theirs default image viewer (eye-of-gnome) and the results very pretty similar ... Gnome's eye-of-gnome was significantly faster (maybe about 20-33% slower than geequie) than gwenview ...

I did another test .. I dropped the cache (`echo 1 > /proc/sys/vm/drop_caches') and made sure that thumbnails are deleted and opened a folder with images and verified, that dolphin (kde) leads the images and creates thumbnails several times longer than nautilus in Gnome .. Again, all with very significant and obvious difference ..

Based on my testing this issue is 100% reproducible .. I was testing that on two different computes (unfortunately both with i7 cpu so no AMD) with two different ways .. I tested it on my `installed' Linux (opensuse with up-to-date KDE + opensuse with older kde, stock Leap 15.6, versions in my first post) ++ I've tested it from live Linux system (live suse Gnome and KDE images) .. Always same result .. KDE is just very slow while working with images ..

I believe that it could be also a culprit for other mentioned bugs ..

I hope it helps ..

thanks much for your input and support ..

cheers, ~dan

there are few typos in my previous message, sorry about that ... I hope it's understandable ... it is still same as in my opening post .. I am just repeating what is in the initial description already ...

I understand the general direction you're going in and how you've explored that on your system, and I don't doubt that there are current inefficiences in how Dolphin scrolls or displays image thumbnails, how Gwenview navigates through images, or how KIO at its core creates thumbnails for those images - and you are likely right that solving core issues here could create cascading benefits across a lot of other processes.

The catch, and the reason I mentioned in my comment that we need distinct issues, is that effectively diagnosing and solving broader topics requires detailing out and working on the individual code bases that are underneath. In your description, you've mentioned:

* Dolphin displaying a folder with thumbnails
* Gwenview scrolling one-by-one through a folder
* Thumbnail generation

Those are undoubtedly all related topics, but they are also distinct issues that should be submitted separately because they each need solved in their own respective components.

Is your theory that the way thumbnails are generated by KIO is at the core of this? If so, then the digging you have done may be helpful information in contributing toward a solution for https://bugs.kde.org/show_bug.cgi?id=445176

Otherwise, if there is a specific display performance issue in Gwenview that you are targeting in this issue, then that is totally fine - but then let's focus this issue on the speed with which Gwenview renders that content, so that can be investigated separately from the back-end generation of thumbnails.

You mentioned that it's not necessarily handling large quantities that you're running into, but performance with particular files - RAW file performance, including for just displaying a single image, has an existing bug here - https://bugs.kde.org/show_bug.cgi?id=454206 - so perhaps the focus here should be the third set of observations you made, regarding JPG loading speed?

Thanks,

Hi John,

thanks for your comment ... yes, my conclusion on what the culprit is and my main point here is the performance issue while opening particular images (doesn't matter if JPGs or RAWs) ..

I don't know howto help further other than reporting it  ... I believe that gwenview is perhaps doing some ineffective handling with files as for instance Fabian mentioned in here https://bugzilla.opensuse.org/show_bug.cgi?id=1230545 that gwenview is unpacking data 3 times and processing them twice ...

OK, please do with this my report whatever you wish .. I am bit afraid that I cannot help further with this because I am not a KDE/Qt developer .. I am only trying to point out that on the high-level there could be easily seen the drastic difference in performance how Qt/kde/gwenview is handling (opening, displaying, loading) image files Vs other FOSS programs that run on the same system with same files significantly faster (3-4 times as per my research) ...

Please close it if this is the right action and if you think that this my report is actually duplicating older bugs ..

thank you very much for your support and for supporting KDE ..

cheers, ~dan

thanks and regards, ~dan

I don't want folks to lose sight of what you've raised, so how about this - there are existing bug reports for thumbnailing performance and RAW image performance as mentioned above, so let's use this one for tracking JPEG loading/displaying performance as I don't see one that addresses that specifically. I believe that would fit with how the work to optimize would be segmented.

Thanks,