[KPhotoAlbum] Thumbnail Performance & Compatibility: ImageManager vs KIO

Johannes Zarl isilmendil at isilme.lupus.uberspace.de
Sat Jun 29 17:05:39 BST 2013


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...


More information about the Kphotoalbum mailing list