Version: 0.9.0 (using KDE 4.2.4) Compiler: gcc-4.3 OS: Linux Installed from: Gentoo Packages Hi Scrolling in digikam's albumview feels extremely slugish here. Also, thumbnail generation is very slow. I know this comparison is not without merits, but gwenview's scrolling in the "album-view" is lighting fast. Admitted, this is an older machine (Athlong 64 3000 and to be replaced in a few days), but the scrolling speed is definatelly sup par Cheers
0.9.0 is a very old version of Digikam, please update and try again.
Gosh, sorry for that.... I ment 0.10.0
Last version for KDE3 is 0.9.6... Gilles Caulier
Not reproducible here. Run digiKam into a console and report all messages displayed... Gilles Caulier
Do you use a special video driver (NVidia for ex), with OpenGL features ? Gilles Caulier
I'm using nvidia-drivers (latest) I get absolutelly no output from digikam while scrolling (I enabled it in kdebugdialog) Is there anything I can do to help?
0.10 is definitely slower than the current 1.0.0-beta versions, since 0.10 still uses the slower thumbnail scaling algorithm. Try 1.0.0-beta4 or current SVN and see if it is getting better (it should).
Okay, I'm now on latest svn (had some troubles with compilation of beta3 which is why it took so long) I'm also on my new machine, a core i7 920 (opposed to a athlon64 3000+...) so a comparison is not easy at all. Thumbnail loading certainly got faster. Of course, scrolling is now pretty fast, but it doesn't feel completely snappy. It uses now about 40% cpu which is for sure 100% on the old machine - and therefore I presume that the feel would still be quite sluggish on my old machine I think some asynchronous scrolling (like gwenview) would make things a lot better
What is asynchronous scrolling?
Basically that means, that the main thread just requests the display of all the images that need to be shown and a second worker thread loads the thumbnails and the metadata (if it's not cached). The main thread just renders a very small svg (like the one gwenview has when the thumbnail is not loaded) This has the effect, that scrolling is very smooth and thumbnails are loaded almost as fast (or even faster when on a multi-core machine as the two threads can be distributed)
We do what is described, with the exception that we dont draw an SVG but nothing if the thumbnail is not in the cache. Maybe we can optimize redrawing a bit. This needs thorough profiling.
SVN commit 1016400 by mwiesweg: Eliminate a source of doube loading of thumbnails: When the QImage is loaded and waiting to be processed to a QPixmap and the same thumbnail is requested again, scan the list of images currently waiting for conversion, and, if found, do not start a new task. To prevent such problems in the future, provide a small cache for thumbnail QImages. CCBUG: 203932 M +1 -1 loadingcache.cpp M +44 -9 thumbnailloadthread.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1016400
To the ones who experience slow scrolling: You should also notice that compiling digiKam with "debug" or "debugfull" will slow down scrolling a lot. To really compare you should compile it with "release" and see if it is getting better.
I just tried the new code - the feel is certainly better on the new machine. CPU usage in scrolling went to 20%, which is a big improvement. Typical - as soon you have a machine there is the need of having the old one :) I can't test there because it's in pieces now, so I don't think I can ask for more
Scrolling seems faster, both in regular Album GUI and thumbbars. But switching between images in Preview mode with thumbbar enabled is very, very slow. With thumbbar disabled it is much faster.
Benjamin, This file still valid using digiKam 2.x serie ? Gilles Caulier
I have a newer machine since I opened this issue. with the new machine, no slowness is visible. However, I cannot really tell whether the issue is gone though. Since the update to kde 4.7.4, digikam crashes on startup so I cannot profile cpu usage during scrolling right now
benjamin, any crash backtrace please, taken with GDB Gilles Caulier
I just recompiled digikam and it works again. (I did not have debug information before) Consider it as a non issue Cheers Benjamin