![]() Registered Member ![]()
|
When I open a folder of images in Gwenview it loads thumbnails for those visible in the browser window. However, if there are more images than will fit into the window the thumbnails for those are not loaded until I scroll down. This means I then have to wait and then repeat however many times it takes to cover the whole folder. Once they have all been loaded in this way I can scroll up and down the folder without problems.
Would it be possible to have gwenview load thumbnails for all the images in a folder into memory when a folder is opened instead of just those that are visible? thanks
bailout, proud to be a member of KDE forums since 2008-Oct.
|
![]() Registered Member ![]()
|
I dislike opening folders with 1,000 plus photos for this very reason. If gwenview insist on it operating like it currently does than at least allows for the option to fetch all thumbnails in a folder and not just the ones visible in the browser.
All answers are all replies, but not all replies are answers.
|
![]() Registered Member ![]()
|
I fully agree - the current thumbnail making behavior makes scrolling quite an unpleasant activity. Weirdly, old gwenview did use to precompute all thumbnails when opening a folder (that was version 1.4 or so), but then this nice ability got dropped. What was the reason for that?
|
![]() Moderator ![]()
|
This feature was dropped because it could easily hammer the memory by loading all thumbnails in large folders. Gwenview is supposed to also load thumbnails for files below the visible ones to compensate a bit, but I agree that is not ideal.
|
![]() Moderator ![]()
|
I worked a bit on it this morning and pushed a branch which implements the generation of all thumbnails, not only the visible ones. It is too late for 4.8.0, but I am going to use it for the month and if it proves to be stable enough, I'll merge it in 4.8.1.
If you are comfortable with building Gwenview from git, I would love to get your feedback. The branch is named "gen-all-thumbnails". |
![]() KDE Developer ![]()
|
Hi agateau:
I'm using gwenview built from that branch. So far so good. As you have mentioned, it really occupies huge memory after I open one folder containing 10K+ photos (created for testing purpose). But the more important problem is in such situation gwenview continues running and consuming more memory after I have closed it through menu. I have to kill it through `killall gwenview` or ksysguard. Maybe huge memory occupation is unavoidable in this rare situation, but it would be better if gwenview can be closed as usual by normal users in this situation. Another related thing: what about the second suggestion in BKO 267261[1], generating thumbnails for files before generating thumbnails for folders? Thanks for your work. [1] https://bugs.kde.org/show_bug.cgi?id=267261 |
![]() Registered Member ![]()
|
Thanks for doing this! I can't wait to try it out.
All answers are all replies, but not all replies are answers.
|
![]() Registered Member ![]()
|
I just built from git. For me this is a big improvement over the previous behaviour. However, I understand the desire not to swamp memory when a very large folder is viewed.
Perhaps putting some sort of configurable cap on memory usage, and caching all thumbs until that limit is exceeded would be a good strategy. What would also be very nice is if there were persistence for cache thumbs across directory changes - provided the memory limit is not exceeded. *edit* and one more idea: a browser-like throbber to show when thumbs are still loading. |
![]() Registered Member ![]()
|
I'm still on KDE 4.6.5 so I think thats the reason why I've been unsuccessful in compiling that particluar branch. Could you tell me the steps you took to compiling gwenview please?
+1 for a memory limit option for cache thumnails. A stop loading all thumbnails option for folders with 500-1000+ photos would be good as for users ywho didn't anticipate significant memory usage.
All answers are all replies, but not all replies are answers.
|
Registered users: Bing [Bot], Evergrowing, Google [Bot], rblackwell