| Summary: | Only generate thumbnail when needed [patch] | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Dik Takken <kde> |
| Component: | Showfoto-Thumbs | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | CC: | amanjmd100, caulier.gilles, mohammed.ahmed.anwer, zeev.tarantov |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 4.0.0 | |
| Sentry Crash Report: | |||
| Attachments: |
This can reduce the Cpu utilization considerably
patch Before Patch After Patch patchAddition patchAddition patch patch |
||
|
Description
Dik Takken
2008-06-05 19:48:31 UTC
Dik, With KDE4, i think that showfoto do not compute thumbs if thumbbar is not displayed. can you check this point ? Gilles Caulier Nobody can confirm comment #1 ? Gilles Caulier KDE 4.4.3, DigiKam 1.20, no thumbnail is saved by showfoto when thumbbar is disabled. zeev, This want mean that this issue is solved with digiKam 1.2.0. right ? Gilles Caulier 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. Gilles Caulier 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]
patch
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]
Before Patch
Created attachment 79883 [details]
After Patch
Created attachment 79885 [details]
patchAddition
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]
patchAddition
Please make a common file, not a puzzle. Use this method to create a patch against git/master code : http://www.digikam.org/contrib Gilles Caulier Created attachment 79928 [details]
patch
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.
Aman
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 Created attachment 79959 [details]
patch
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.
|