Version: 0.9.0-Beta2 (using KDE KDE 3.5.4) Installed from: Gentoo Packages OS: Linux Scrolling the thumbnail view up and down feels very sluggish. All available CPU power is used for scrolling thumbnail view. The album view in DigiKam main window is lightning fast in comparison.
Not reproductible here using UMS and PTP camera drivers... Are you using a Gphoto2 camera drivers ? Can you test with beta3 ? http://digikam3rdparty.free.fr/0.9.0-beta3 Gilles Caulier
Dik, Some fresh new using last stable 0.9.2 ? Gilles
No difference performance-wise in Digikam 0.9.2... I must admit that my computer is a 7-year-old 800 MHz Athlon, but still I feel that scrolling should not be much of a problem. Anyway, I don't understand why there should be a significant performance difference between the main window and the camera dialog. In case it is of any use: The gphoto2 output when downloading manually is: gphoto2 2.3.1 Copyright (c) 2000-2006 Lutz Mueller and others gphoto2 comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of gphoto2 under the terms of the GNU General Public License. For more information about these matters, see the files named COPYING. This version of gphoto2 is using the following software versions and options: gphoto2 2.3.1 i686-pc-linux-gnu-gcc, popt(m), exif, cdk, no aa, no jpeg, readline libgphoto2 2.3.1 i686-pc-linux-gnu-gcc, ltdl, EXIF libgphoto2_port 0.7.1 i686-pc-linux-gnu-gcc, ltdl, USB, serial without locking Detected a 'Canon:PowerShot A400'.
Dik, The thumbs handling in Camera GUI and Album GUI is different about cache mechanism. Album GUI cache all thumbs on the disk and a few on memory. Camera GUI cache _all_ thumbs in memory because no cache mechanism on the disk can be done with removable media. You have certainly not enough memory space available, and your computer swap, especially when your camera memory device is full of pictures. Here with 1 Gb of RAW all is fine to display contents of more than 400 items in camera. Gilles
Hmmm... I do not have any disk activity while scrolling.... I got 384 MB of RAM and digikam only uses about 20%. The camera contains only 100 3.2 Megapixel JPEG images. It's only CPU number crunching that is going on while scrolling. Digikam needs 75% CPU and X needs 25. These numbers suggest that the drawing of the thumbs requires a LOT of computation. I don't use X Composite or anything fancy like that.
Dik, Which camera you use. Which driver you use (look in Help/Camera Info dialog from Camera Gui) If you use a Gphoto2 drivers, thumbnails extraction is performed by Gphoto2. But this is really strange because thumbs process must be forked in a separate thread which will not freeze the GUI... Can you check is a separate thread is created properly when you access to your camera ? Note : i have an old Toshiba-satellite laptop using PIII-650Mhz/350Mb RAM. There is no gui freeze during thumbs extraction. Of course thumbs are slow to appears on icon view but Camera gui still alive everytime. Gilles
I use a canon powershot A400 using the Canon PowerShot series driver. Note: There are no freezes in the GUI, it stays fairly responsive all the time. The slow response is also there when all thumbs have been downloaded. Only the scrolling of the thumb view is causing huge CPU loads. This has nothing to do with downloading the thumbs or anything. I tried this on a new laptop also, and the scrolling is laggy on that machine as well...
Dik, What's news about this file ? It still valid to use digiKam 0.9.4 and a recent libgphoto2 ? Gilles Caulier
I can confirm, KDE3 version is like 5 times faster... both Album GUI and Camera GUI Andi
Andi, Is like 5 times faster than what ? Gilles
The scrollview in KDE3 is much more responsive than in KDE4. Scrolling the thumbview in KDE4 is like having digikam installed on my old PII-90MHz PC. But I have a Core2Duo machine here. Also thumb generation is much much faster in KDE3. But this is no KDE4 problem in general, because Gwenview and other applications scroll smooth. Andi
SVN commit 898855 by cgilles: digiKam from trunk: Memory optimizations of Camera Interface: - Do not store image thumbnails as QImage but as QPixmap. - Store only one reference of newPicture and unknowPicture pixmap to icon view instance, not in each icon view item instances. CCBUGS: 135845 M +8 -141 cameraiconitem.cpp M +147 -5 cameraiconview.cpp M +3 -1 cameraiconview.h WebSVN link: http://websvn.kde.org/?view=rev&revision=898855
Dik, In digikam for KDE4 (trunk, 0.10.0-beta8), i have fixed several memory consuming... Please, give me a fresh feedback about this entry. Thanks in advance Gilles Caulier
(In reply to comment #11) > The scrollview in KDE3 is much more responsive than in KDE4. Scrolling the > thumbview in KDE4 is like having digikam installed on my old PII-90MHz PC. But I > have a Core2Duo machine here. Also thumb generation is much much faster in KDE3. I just wanted to add that the performance issue is related to my NVIDIA driver. I upgraded to a new version and everything is fast, scrolling, thumb generation etc. Only drawback: The driver sucks :-) I get artifacts all over plasma and then KDE crashes. Same for KDE3 so this is not related to KDE4. I rolled back to my old driver, now everything sucks again due to performance issues:D But at least I have no crashes anymore. Andi
I'm running 180.37 of the nVidia-driver. Everything i smooth _except_ scrolling in digikam's thumb-view and a few other things. But one thing I have noticed is that if I enable kwins possibillity of show what is actually been drawn the whole thumb-view is updated when changing the selected thumbnail. In my world it should only update the thumbnail that looses selection and the one that gets selected. Since I don't know how kwin registers what is being redrawn this is only thoughts, but maybe some of you guys know what happens. Btw. the excess redraw also happenens in kile, kwrite, kdevelop, kate.
oh yes ...... I'm running digikam 0.10 on ubuntu jaunty
So, this problem is not relevant of digiKam icon view. right ? Gilles Caulier
I don't think so. It is related to NVidia on my system. Without the nvidia driver (vesa) or OpenGL support it is damn slow. Maybe the new iconview will speed this up even further, because at the moment it is only a Q3Support class. Andi
This is Q3Support related. Long lists where damn slow with this. For example KMail for KDE4 was totally unusable with folders of more than 8000-9000 items. Only after port to Qt4 list model view it was fixed. So I think that should be fixed with latest work on icon view.
Mik, i think whole KDE4 as problem to enable by default all video effect everywhere. If you don't have an OpenGL compliant video card, it become unsuitable. Go to KDE control pannel, and ajust settings to minimum. It's better. Gilles Caulier
It wasn't related to OpenGL at all. I tried KMail with different settings and nvidia drivers and everything was crap until port to Qt4 list model.
This has been fixed for a while now. Please close this bug.
Soren, are you sure ? Gilles Caulier
It definetly is ok now. Sorry for the WAY to late reply.