Lots of thumbnail requests with invalid size
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
thumbnailer (Ubuntu) |
Invalid
|
High
|
Unassigned | ||
unity8 (Ubuntu) |
Fix Released
|
High
|
Unassigned |
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/
Related branches
Changed in thumbnailer (Ubuntu): | |
importance: | Undecided → High |
Changed in unity-scopes-shell (Ubuntu): | |
importance: | Undecided → High |
tags: | added: invalid-qsize |
Changed in unity-scopes-shell (Ubuntu): | |
status: | New → Invalid |
Changed in unity-scopes-shell (Ubuntu): | |
status: | Invalid → New |
Changed in thumbnailer (Ubuntu): | |
status: | New → Invalid |
I think this is actually on the Unity8 side rather than unity-scopes-shell.
The result cards are generated by CardCreator.js, which uses a CroppedImageMin imumSourceSize component to display the result art:
http:// bazaar. launchpad. net/~unity- team/unity8/ trunk/view/ head:/plugins/ Dash/CardCreato r.js#L101
This component is implemented in QML but delegates finding the size of the image to the C++ component CroppedImageSizer
http:// bazaar. launchpad. net/~unity- team/unity8/ trunk/view/ head:/plugins/ Dash/CroppedIma geMinimumSource Size.qml
That class uses QNetworkAccessM anager to try and get the file contents and uses a helper class to manage the response:
http:// bazaar. launchpad. net/~unity- team/unity8/ trunk/view/ head:/plugins/ Dash/croppedima gesizer. cpp#L102
That helper tries to read the returned data via QImageReader and passes the image size back to CroppedImageSizer:
http:// bazaar. launchpad. net/~unity- team/unity8/ trunk/view/ head:/plugins/ Dash/croppedima gesizerasyncwor ker.cpp# L58
If the worker provides a non-empty size, CroppedImageSizer then uses that size information to pick a sourceSize value that will result in the image being loaded at the correct size so it only has to be cropped in at most one dimension to fit. If an empty (or invalid) size is provided, it sets sourceSize to (0, 0):
http:// bazaar. launchpad. net/~unity- team/unity8/ trunk/view/ head:/plugins/ Dash/croppedima gesizer. cpp#L118
This causes a problem for the thumbnailer because QNetworkAccessM anager has no idea how to deal with image:// URIs, so we get an invalid QSize from the worker and use a sourceSize of (0, 0). Perhaps it should just use the requested dimensions in this case instead. It doesn't look like there is a way to handle this crop mode properly with QQuickImageProv ider.