Bug 163293 - Only generate thumbnail when needed [patch]
Summary: Only generate thumbnail when needed [patch]
Alias: None
Product: digikam
Classification: Unclassified
Component: Showfoto-Thumbs (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR wishlist (vote)
Target Milestone: ---
Assignee: Digikam Developers
Depends on:
Reported: 2008-06-05 19:48 UTC by Dik Takken
Modified: 2022-02-05 04:57 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.0.0

This can reduce the Cpu utilization considerably (37.47 KB, text/x-c++src)
2013-05-07 19:40 UTC, AMAN KAOOR
patch (1.49 KB, patch)
2013-05-14 13:07 UTC, AMAN KAOOR
Before Patch (70.25 KB, image/png)
2013-05-14 13:08 UTC, AMAN KAOOR
After Patch (65.01 KB, image/png)
2013-05-14 13:08 UTC, AMAN KAOOR
patchAddition (1.01 KB, patch)
2013-05-14 14:14 UTC, AMAN KAOOR
patchAddition (1.12 KB, patch)
2013-05-14 14:21 UTC, AMAN KAOOR
patch (1.92 KB, patch)
2013-05-17 09:00 UTC, AMAN KAOOR
patch (1.41 KB, patch)
2013-05-19 05:57 UTC, AMAN KAOOR

Note You need to log in before you can comment on or make changes to this bug.
Description Dik Takken 2008-06-05 19:48:31 UTC
Version:           0.8.0 (using KDE 3.5.8)
Installed from:    Gentoo Packages
OS:                Linux

When an image is loaded in ShowFoto, a thumbnail generator process is launched. I guess this process is supposed to generate the thumbnail for the thumb bar.

When loading a very large image, the thumbnail generation causes a huge additional memory and CPU load. I tried disabling the thumb bar, but the thumbnail is generated anyway.

When the generator could only be launched when needed, it would be major improvement of the startup time of ShowFoto.
Comment 1 caulier.gilles 2008-12-10 19:32:33 UTC

With KDE4, i think that showfoto do not compute thumbs if thumbbar is not displayed. can you check this point ?

Gilles Caulier
Comment 2 caulier.gilles 2009-07-22 15:16:46 UTC
Nobody can confirm comment #1 ?

Gilles Caulier
Comment 3 Zeev Tarantov 2010-04-07 23:27:36 UTC
KDE 4.4.3, DigiKam 1.20, no thumbnail is saved by showfoto when thumbbar is disabled.
Comment 4 caulier.gilles 2010-04-08 09:20:01 UTC

This want mean that this issue is solved with digiKam 1.2.0. right ?

Gilles Caulier
Comment 5 Zeev Tarantov 2010-04-08 19:09:05 UTC
The original reporter of the bug was concerned with cpu and memory usage.
I only verified that the thumbnail was not saved (I looked at the thumbnails directory), I didn't verify it was not generated. If, hypothetically, the thumbnail was generated and discarded, then the CPU was still used. I didn't run the program in a debugger or measure CPU usage. The read IO happened from a worker thread both times (with and without thumbbar).
Comment 6 caulier.gilles 2010-04-08 19:18:38 UTC
thumbs are not saved in your ~/.thumbnails dir but in a database file with digiKam 1.2.0

So, the only to check if this file is fixed is to see CPU charge.

Gilles Caulier
Comment 7 Zeev Tarantov 2010-04-09 00:10:29 UTC
showfoto 1.2.0 very much saves standalone png files under ~/.thumbnails/ on my computer.
Comment 8 AMAN KAOOR 2013-05-07 19:40:43 UTC
Created attachment 79764 [details]
This can reduce the Cpu utilization considerably

I have disconnected the connection
"connect(d->thumbLoadThread, SIGNAL(signalThumbnailLoaded(LoadingDescription,QPixmap)), this,SLOT(slotGotThumbnail(LoadingDescription,QPixmap)));
which prevents the initial repainting of the thumbnails as defined in the slotGotThumbnails in the file and this reduces CPU cycles.
Sir Gilles Please review it.
Comment 9 AMAN KAOOR 2013-05-14 13:07:46 UTC
Created attachment 79881 [details]

I am submitting the patch.
I have also uploaded images "Before Patch" & "After Patch" to show the difference.

Sir Gilles, Please review it.
Comment 10 AMAN KAOOR 2013-05-14 13:08:27 UTC
Created attachment 79882 [details]
Before Patch
Comment 11 AMAN KAOOR 2013-05-14 13:08:51 UTC
Created attachment 79883 [details]
After Patch
Comment 12 AMAN KAOOR 2013-05-14 14:14:17 UTC
Created attachment 79885 [details]

Sir I have forgot to include two other lines to include in the previous patch.
So I am submitting an addition to my patch "patchAddition" to patch those lines also.
Comment 13 AMAN KAOOR 2013-05-14 14:21:14 UTC
Created attachment 79886 [details]
Comment 14 caulier.gilles 2013-05-14 15:00:01 UTC
Please make a common file, not a puzzle. Use this method to create a patch against git/master code :


Gilles Caulier
Comment 15 AMAN KAOOR 2013-05-17 09:00:26 UTC
Created attachment 79928 [details]

Hi Gilles,

Sorry for the puzzle. I have attached  the final patch and have removed all the previous ones.

The repaint function called in slotGotThumbnail was painting the pixmap to the rectangles , before the viewportPaintEvent ,which was causing an extra  CPU usage . If this Slot is not called, only the viewportPaintevent function paints the pixmap , not the contentsRepaint() ,thereby reducing the CPU usage.
In this patch, I have removed slotGotThumbnail function and its connections as it's functions are already being performed by viewportPaintEvent and there is no need to slotGotThumbnail to load the thumbnails.
Removing this function decreases the cpu usage of all cores to a great extend as shown in the images.

Please review it.

Comment 16 caulier.gilles 2013-05-17 09:04:13 UTC
One question : 

1/ I load and image in showfoto
2/ thumbail is generated accordingly
3/ I transform photo (ex : rotate 90°)
4/ thumbail is generated accordingly ? (not necessary typically)
5/ I save image (overwrite)
6/ thumnail is generated accordingly ? (mandatory)

Gilles Caulier
Comment 17 AMAN KAOOR 2013-05-19 05:57:49 UTC
Created attachment 79959 [details]

Hi Gilles,

It was right that In my previous patch  ,the thumb-bar was not updated on transformation of any of the images because I removed the slotGotThumbnail and its connection from the thumbnailload thread, so it was not able to repaint the changes in image, in the thumb-bar after the image was transformed.

So in this patch I removed the connection from the constructor, so that initial loading and painting is done only by viewportPaintEvent, and not the slotGotThumbnail item->repaint() function which is causing the extra painting computation .I have transferred this connection to the void ThumbBarView::invalidateThumb function , which is called only when we save the transformed image. Because it is called by the item url ,so the item->repaint() function is only called for the item which is transformed and the item is repainted.

I am submitting the new patch obseleting the previous one. Please review it.