[KPhotoAlbum] Thumbnail Performance & Compatibility: ImageManager vs KIO
Johannes Zarl
isilmendil at isilme.lupus.uberspace.de
Sat Jun 29 17:05:39 BST 2013
Hi,
I'm wondering if it might be worthwhile to make use of KIO::PreviewJob in the
ImageManager. I'm currently getting the feeling that doing all thumbnailing on
our own creates a maintenance-burden that outweighs potential benefits of the
current system.
It's not that ImageManager is inherently doing things in a bad way, but
together with the BackgroundJobs system it forms a complex entity that is IMO
quite hard to debug, especially when it comes to performance problems.
The way I see it, there are several nice things about the current system:
+ Job priorities
+ Animated video thumbnails
OTOH, it has some disadvantages:
- no thumbnail sharing with other applications
(i.e. twice the time spent on thumbnailing)
This could also be dealt with by changing the ThumbnailCache.
- dependence on mplayer for video thumbnails
(mplayer is not shipped by every distro)
Using KIO::PreviewJob would automatically make the cached thumbnails available
for other applications (not just KDE), and at least provide a fallback for
video thumbnails when mplayer is not available. It could also reduce the
frustration for users who are beginning with KPA and have to wait for the
thumbnail cache to be built.
I guess there are several ways we could make use of KIO::PreviewJob in KPA:
a) Throw out ImageManager completely, use PreviewJob everywhere.
b) Use the scheduling of ImageManager to manage PreviewJobs,
use PreviewJobs for images and videos.
c) Like b), but keep the custom code for video thumbnails.
Anyone has any thoughts on this?
Jesper: you wrote the whole ImageManager code. I guess you had some reason not
to use PreviewJob at that time? I don't want to go jumping out of the frying
pan into the fire...
Cheers,
Johannes
More information about the Kphotoalbum
mailing list