Directory thumbs are a composite of thumbnails of content within that directory. The content thumbs are already cached so that's cool. But the composite appears to get generated over and over again even when its content hasn't changed. This could be improved somewhat easily... - cache the composite with a bit of proprietary attribute since the spec has no useful existing [1]. X-KDE::DirParts or somesuch, a comma separated list of md5sums of thumbnails comprising the composite - on thumbnail attempts (if cache for dir exists): -- load cache -- read DirParts attribute -- iterate directory -- foreach dirent ---- createThumbOrLoadFromCache ----- is md5 NOT in DirParts -> invalidate dir cache and re-composite -- if selected md5s.count < DirParts.count re-composite (e.g. previewable content went from 4 to 3) This would then mean that dir previews do not change unless the underlying parts change. [1] https://specifications.freedesktop.org/thumbnail-spec/thumbnail-spec-latest.html
For a complete, correct implementation, you have to: - Fetch the cached directory thumbnail - Get the base folder icon (thats the reason KFileItem::iconName is used) -> If the base icon changed, DoRecomposite=true - Iterate the directory, for each entry up to 4: -- create the URL MD5 -- read the MTime -- check if the thumb is cached and if the MTime matches (1) --- if not, (Re)Create the item thumbnail -> DoRecomposite=true - If DoRecomposite, create the directory thumbnail, else fetch So, you need the following metadata in the dir thumbnail: - base icon name and theme (still not sufficient, appearance may change) - URL MD5, MTime Now, the next complication is, directory thumbnails are ThumbSequences, so you get one cached dir thumb for subitems 1-4, one for 5-8, 9-12, ... Do you really see compositing the icon as some kind of bottleneck? (1) This can either be done per individual thumbnail, or, in your proposal, from a composite key in the directory thumbnail. If you don't save the MTime in the directory thumb meta, you have to load each item thumbnail.
Perhaps bug 423537 would bring better improvements for less work. The trouble is that if you browse around a huge dir tree as described in https://bugs.kde.org/show_bug.cgi?id=178678#c71 the triviality of composition becomes all extra work and a huge waste. I got it to hang on IO a couple of times over the network while doing directory thumbing but there's multiple levels to this, bug 178678 has a bunch of related reports which overlap more aggressive caching (e.g. KFileItem::iconName bug #423499 would help tremendously as well).