Version: 0.8.0 (using KDE 3.5.8)
Installed from: Gentoo Packages
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.
With KDE4, i think that showfoto do not compute thumbs if thumbbar is not displayed. can you check this point ?
Nobody can confirm comment #1 ?
KDE 4.4.3, DigiKam 1.20, no thumbnail is saved by showfoto when thumbbar is disabled.
This want mean that this issue is solved with digiKam 1.2.0. right ?
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).
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.
showfoto 1.2.0 very much saves standalone png files under ~/.thumbnails/ on my computer.
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.
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.
Created attachment 79882 [details]
Created attachment 79883 [details]
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.
Created attachment 79886 [details]
Please make a common file, not a puzzle. Use this method to create a patch against git/master code :
Created attachment 79928 [details]
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.
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)
Created attachment 79959 [details]
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.