Bug 114240 - Thumbnail reloading time exessive
Summary: Thumbnail reloading time exessive
Status: RESOLVED DUPLICATE of bug 267261
Alias: None
Product: gwenview
Classification: Applications
Component: general (other bugs)
Version First Reported In: unspecified
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Gwenview Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-11 21:21 UTC by Eli
Modified: 2013-04-03 13:40 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eli 2005-10-11 21:21:31 UTC
Version:           1.3.0 (using KDE KDE 3.4.0)
Installed from:    SuSE RPMs
Compiler:          gcc/++ 3.3.5 
OS:                Linux

When switching between folders with large numbers of pictures in them, Gwenview regenerates the thumbnails. This causes a loss of "responsiveness" when managing pictures.

Assume folders A, B, C and D.
A has 11 pictures
B has 22 pictures
C has 166 pictures
D has 40 pictures.

Start the program, look in A. Thumbnails generate. Switch to B. Thumbails generate. Switch back to A, thumbnails pop up instantly, as expected. Switch to B, thumbnails pop up instantly. Now switch to C. Thumbnails generate. Switch back to A, thumbnails regenerate rather than pop up as before. Switch back to C, thumbnails regenerate rather than pop up.

It seems like the thumbnails are not being saved to disk and are only being cached in memory. 

I hope this description of symptoms makes sense. Thanks.

Eli
Comment 1 Aurelien Gateau 2005-10-11 23:42:03 UTC
Le Mardi 11 Octobre 2005 21:21, Eli a écrit :
> When switching between folders with large numbers of pictures in them,
> Gwenview regenerates the thumbnails. This causes a loss of "responsiveness"
> when managing pictures.
>
> Assume folders A, B, C and D.
> A has 11 pictures
> B has 22 pictures
> C has 166 pictures
> D has 40 pictures.
>
> Start the program, look in A. Thumbnails generate. Switch to B. Thumbails
> generate. Switch back to A, thumbnails pop up instantly, as expected.
> Switch to B, thumbnails pop up instantly. Now switch to C. Thumbnails
> generate. Switch back to A, thumbnails regenerate rather than pop up as
> before. Switch back to C, thumbnails regenerate rather than pop up.
>
> It seems like the thumbnails are not being saved to disk and are only being
> cached in memory.
>
> I hope this description of symptoms makes sense. Thanks.


There is an option in the configuration dialog which let you choose if you 
want to cache thumbnails on disk. Did you try to activate it?

Aurélien
Comment 2 Eli 2005-10-13 00:38:49 UTC
On Tuesday 11 October 2005 15:42, Aurelien Gateau wrote:
> Le Mardi 11 Octobre 2005 21:21, Eli a écrit :
> > When switching between folders with large numbers of pictures in them,
> > Gwenview regenerates the thumbnails. This causes a loss of
> > "responsiveness" when managing pictures.
> >
> > Assume folders A, B, C and D.
> > A has 11 pictures
> > B has 22 pictures
> > C has 166 pictures
> > D has 40 pictures.
> >
> > Start the program, look in A. Thumbnails generate. Switch to B. Thumbails
> > generate. Switch back to A, thumbnails pop up instantly, as expected.
> > Switch to B, thumbnails pop up instantly. Now switch to C. Thumbnails
> > generate. Switch back to A, thumbnails regenerate rather than pop up as
> > before. Switch back to C, thumbnails regenerate rather than pop up.
> >
> > It seems like the thumbnails are not being saved to disk and are only
> > being cached in memory.
> >
> > I hope this description of symptoms makes sense. Thanks.
>
> There is an option in the configuration dialog which let you choose if you
> want to cache thumbnails on disk. Did you try to activate it?
>
> Aurélien


Thanks for your quick reply.

My settings are as follows:

Settings - Configure Gwenview - Image List:
  Configure Image List
    (X) Show Folders and archives
  Thumbnail View
    Margin between thumbnails: 5
  Information to display in the thumbnail text:
    (X) File name
    (X) Image size
  Thumbnail Cache
    (X) Store thumbnails in cache

I thought that perhaps I had not set something like this and rechecked it many 
times before deciding it was indeed a bug and not my own stupidity (of which 
I have plenty). So it looks like something is wrong somewhere. (Unless my 
stupidity is really taking over this week)

The permissions on ~/.thumbnails are drwx------, and contains two 
subdirectories: normal (with 1715 entries), large (with 191). They have the 
same permissions as the parent directory.

I rechecked the version I am running, and it is indeed 1.3.0, under KDE 3.4.0 
level "b", SuSE 9.3, Linux (i686) 2.6.11.4-20a-default

Thanks,

Eli
Comment 3 Lubos Lunak 2005-10-13 16:43:42 UTC
When the thumbnails appear almost instantly, they don't come from the disk cache but from the memory cache. Which has a limited size. If you use 100x100 thumbnails, those 166 thumbnails take more than 6MB memory, and the cache also stores fullsized images and other things. So this is not really a bug.
The thumbnails spec doesn't seem to care that much about performance, using it in Gwenview reduces the thumbnail generation time to only about one third. I'd expect using a different format for saving more suited for fast loading would give much faster loading times.
Comment 4 Eli 2005-10-14 07:10:16 UTC
On Thursday 13 October 2005 08:43, Lubos Lunak wrote:
> ------- Additional Comments From l.lunak kde org  2005-10-13 16:43 -------
> When the thumbnails appear almost instantly, they don't come from the disk
> cache but from the memory cache. Which has a limited size. If you use
> 100x100 thumbnails, those 166 thumbnails take more than 6MB memory, and the
> cache also stores fullsized images and other things. So this is not really
> a bug. The thumbnails spec doesn't seem to care that much about
> performance, using it in Gwenview reduces the thumbnail generation time to
> only about one third. I'd expect using a different format for saving more
> suited for fast loading would give much faster loading times.


Okay. I can see why the performance might not be what I might expect, which 
might place this in the realm of not-really-a-bug. Making it more of a 
complaint about not-really-a-feature I guess.  ;)  I really do like this 
program, except for this problem.

Just to make the symptom clearer, here is some additional information. If I 
turn off the "store in cache" feature, the program behaves exactly the same 
way, with exactly the same thumbnail generating time as when the feature was 
turned on. Measured by my watch, eyeballs and patience anyway. In other 
words, it does in fact look like it is only reloading thumbnails from the 
limited in-memory cache, never (or rarely) reading from the disk cache, 
thereby necessitating regeneration of thumbnails. Both cache on and cache off 
results in a little progress bar in the lower right showing how many out of 
how many as it churns slowly along. 

Examining the contents of .thumbnails/normal reveals 152 png images with 
October dates (installed on the 8th). I have visited close to 2000 pictures 
with the "store in cache" feature enabled. Shouldn't they all be in 
that ./thumbnails directory? Of these, only some of them say they belong to 
Gwenview - most others claim to be from the KDE thumbnail generator.

Assuming it is not a bug, I guess I was expecting the same fast thumbnail 
performance that PixiePlus posseses,  from which I switched. Thumbnails 
generated in Pixie, for the same directories I am managing with Gwenview, pop 
up extremely quickly - like almost instantly. No matter how many directories 
I visit or thousands of pictures I browse.

If this truly is the speed at which Gwenview reloads thumbnails from disk 
cache, then somebody might want to have a look at Pixie and see how it 
handles this feature, because it is like comparing a Cheetah to a Sloth. 
Somewhere in the docs or source to Pixie it mentions only doing on-demand 
loading, rather than loading the entire directory. This greatly reduces the 
amount of time spent loading from disk cache, and allows more responsiveness 
to the user when navigating through hundreds or thousands of images. I do not 
know how Gwenview handles it. Perhaps this is not a bug, or perhaps it is. 
Maybe I should roll up my pantlegs and wade into this feature in Gwenview and 
figure it out. 

Thanks very much for your help,

Eli   :)
Comment 5 Aurelien Gateau 2005-10-15 00:27:30 UTC
Le Vendredi 14 Octobre 2005 07:10, Eli a écrit :

> Examining the contents of .thumbnails/normal reveals 152 png images with
> October dates (installed on the 8th). I have visited close to 2000 pictures
> with the "store in cache" feature enabled. Shouldn't they all be in
> that ./thumbnails directory? Of these, only some of them say they belong to
> Gwenview - most others claim to be from the KDE thumbnail generator.


Yes they should definitely be in the .thumbnails directory. If I remember 
well, the only reason an image would not end up with a thumbnail in 
the .thumbnails dir is if the original image is smaller than the thumbnail. 
In this case we just use the original instead.

If you can build Gwenview from source, maybe you can try editing the file 
gvcore/thumbnailloadjob.cpp and change the line that says:
  //#define ENABLE_LOG
to:
  #define ENABLE_LOG
and rebuild Gwenview.
Then, delete your .thumbnails dir, start Gwenview from the console and browse 
a few directories. It should produce lots of output on the standard output, 
please post/attach the output to this bug.

Aurélien
Comment 6 Ferdinand Gassauer 2006-08-26 09:26:32 UTC
Gwenview 1.3.93 SVN + KDE SVN of today

the startup time is still slow (30 seconds... AMD 64 + 1 GB)

for opening ONE image it seems that gwenview is parsing all files. (about 1000 in that directory)

a) give feedback during this time
b) thumbnails should be optional - and eventually a background process.

the calculated cache size for thumbnails is about 400 MB !!!
 - I do not need them - I'd like to turn them off

the way it works now renders gwenview unusable for large image collections
Comment 7 Mark S. 2011-12-28 02:22:33 UTC
This bug has not been updated in 5 years. Is still an issue? Also, it appears to be related to bug 267261
Comment 8 Myriam Schweingruber 2012-01-02 18:33:51 UTC
*** Bug 267261 has been marked as a duplicate of this bug. ***
Comment 9 Myriam Schweingruber 2012-01-02 18:34:42 UTC
Setting status correctly.
Comment 10 Myriam Schweingruber 2013-04-03 13:40:38 UTC

*** This bug has been marked as a duplicate of bug 267261 ***