So, here is some history of this. The old thumbnailer, when presented with (-1,-1), delivered a 512 thumbnail. That wasn't really by design, but a side-effect of how the code was written. When we changed to the new thumbnailer, we decided to return the full-size image for an invalid QSize.
That turned out to be a mistake: when we ran a bunch of apps and scopes against the new thumbnailer, we found that there were lots of cases were the caller passed an uninitialized QSize, and we returned a full-size image in response. To the caller, everything appears to be working correctly, but it's working horribly inefficiently, both in terms of disk space and in terms of scaling. If the caller wants a full-size image, it can do that, by asking for (0, 0). The advantage is that asking for a full-size image becomes an explicit operation, so it won't happen by accident. I don't quite understand why you need to know the aspect ratio beforehand. Surely, there must be some display size into which the thumbnail is expected to fit? If we get something like QSize(512, 0) or (0, 512), we assume a 512x512 bounding box and scale accordingly. (We always preserve aspect ratio.) So, why not use that? And, if you really want a full-size image, just ask for (0,0) and you'll get it. But we can't return a full-size image for an uninitialized QSize; all that does is hide errors and it causes things to run horribly inefficiently. Returning some other size for (-1,-1) will be wrong most of the time for most callers, no matter what size we pick. It'll be too small and look bad, or it'll be too large and inefficient. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to thumbnailer in Ubuntu. https://bugs.launchpad.net/bugs/1467740 Title: Lots of thumbnail requests with invalid size Status in thumbnailer package in Ubuntu: New Status in unity8 package in Ubuntu: New Bug description: When using scopes, the thumbnailer gets loads of requests with QSize(-1,-1) from the shell. For example, with a bunch of videos recorded, run up the video scope and go to "My Videos". The shell asks for a thumbnail at QSize(-1,-1) for the tiny thumbnail that appears to the left of each list entry. The problem with this is that the thumbnailer interprets this to mean "give me the largest size you can (limited to a 1920x1920 bounding box). That's very expensive, especially in terms of disk space, because that 1920 "thumbnail" ends up going into the cache, needlessly hogging space. We are about to add a qWarning message to the QML side that reports invalid QSize requests. For now, we are going to retain the old behavior, but this will turn into an error soon. The most effective way to use the thumbnailer is to simply ask for an image in the desired size, with neither width nor height of -1. The thumbnailer will efficiently produce a thumbnail for that. (We do lots of internal caching to avoid extracting or downloading a thumbnail unnecessarily.) The thumbnailer may deliver a thumbnail that is smaller than what was asked for (because it never up-scales) so, if asked for a thumbnail of size 256, it's guaranteed not to be larger, but might be smaller (if the original image is smaller than what was asked for). Could you please adjust the shell behavior to ask for specific, valid sizes only? Running a tail -f on ~/.cache/upstart/dbus.log allows you to see the requests as they are made. Each request shows the size that was asked for. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/thumbnailer/+bug/1467740/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
