Comment 19 for bug 1550706

> Still a bit wondering why it does implement the scaling of local images use case then at all and does not just media artwork matching/fetching alone then.

From the application perspective, it wants to say "give me an image in such and such a size for this thing", where the thing could be just about anything (image, video, audio, plus others we might add in the future). Extraction of the images is not simple because we have to deal with many different media types, and applications shouldn't be burdened with that. Images can also be encoded in many different formats, and they may need rotating in some cases. And doing all of this in a way that is scalable and efficient is very much non-trivial. The thumbnailer handles all of these things transparently for applications.

Because applications tend to ask for an image in only a limited number of small sizes, it makes sense to do the scaling inside the thumbnailer because it caches the scaled images. In turn, we get much bigger bang for our disk space. Storing the scaled image also means that the Qt/QML layer doesn't have to repeatedly scale down images on the fly, which burns a lot of battery, and retrieving an already-cached thumbnail is lightning fast.

If all you need is image scaling from pre-existing image files (not other media files) or image contents, things are not hard to do in C++. We already have an Image class that does all the scaling/rotation work, and the C++ cache takes care of the caching. Both APIs are simple and small. pesistent-cache-cpp is already available as stand-alone library, and the Image class is small, one source file, maybe around 300 lines of code. It only needs gdk_pixbuf and libexif to work.

So, creating a QML stand-alone module that can do this might really be the best way to go. The persistent cache does not provide an async interface, but it would be easy to use a QThreadPool with a single thread to make it async. (Making the Image class async is probably not worth it, I suspect it'll always be fast enough.)

Architecturally, I think that's cleaner too. For one, no need to call things over DBus, install a separate service, etc. And there are no security issues to deal with because this would all run embedded in the calling application. This seems better to me than trying to shoehorn the thumbnailer into doing things it wasn't designed for.