Thumbnail generation is slow when requesting a sourceSize that needs to be rescaled

Bug #1391368 reported by Victor Thompson
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Canonical System Image
High
Unassigned
Thumbnailer
Fix Released
Undecided
Unassigned
thumbnailer (Ubuntu)
Undecided
Unassigned
thumbnailer (Ubuntu RTM)
Undecided
Unassigned

Bug Description

The music app sets the "sourceSize" property of the Image component used for the Thumbnailer image provider. The values used are based on the size of the displayed image. For instance, on a Nexus 4 in the Music app's Albums tab this appears to be either "330" or "165" depending on if it is the full image or if is part of a quadrant/grid. However, setting the sourceSize to these values causes the thumbnailing processing to be extremely slow. Simply requesting that the source be 512 (which is the size of the xlarge) art is much faster--because I assume the image is not resized.

One or both of the following could/should be done 1) the resizing needs to be made significantly faster, and/or 2) there needs to be an API that provides a property so users of the Thumbnailer can request sizes of 128 (normal), 256 (large), or 512 (xlarge). Hardcoding these values in the app would cause regression if the Thumbnailing service ever changed the corresponding default sizes. Ideally I think both of these enhancements should be made.

Related branches

Revision history for this message
Jussi Pakkanen (jpakkane) wrote :

Image scaling is done by external libraries such as Qt, so thumbnailer can't really do much to make it faster. I'd imagine those libraries are already relatively fine tuned.

The image sizes that the thumbnailer stores come from the freedesktop.org thumbnailing standard. It has not changed in years and is not expected to. So the simplest thing is to just grab the size that is the fastest.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package thumbnailer - 1.3+15.04.20150122-0ubuntu1

---------------
thumbnailer (1.3+15.04.20150122-0ubuntu1) vivid; urgency=low

  [ Florian Boucault ]
  * Keeps track of failed thumbnails and do not try to regenerate them.
    (LP: #1389678)
  * QML thumbnail provider: make sure sourceSize (aka requestedSize) is
    respected by downscaling at loading time if necessary. Makes
    TN_SIZE_ORIGINAL case much faster. (LP: #1391368)
 -- Ubuntu daily release <email address hidden> Thu, 22 Jan 2015 08:56:16 +0000

Changed in thumbnailer (Ubuntu):
status: New → Fix Released
Changed in canonical-devices-system-image:
importance: Undecided → High
milestone: none → ww05-2015
status: New → In Progress
Revision history for this message
Jussi Pakkanen (jpakkane) wrote :

I did some testing and rescaling a 1024ish image to 360ish takes on the order of 0.05 seconds. Thus is it unlikely that scaling is the cause of this slowdown. Is this still happening on newest images that have Florian's fix from above?

Changed in canonical-devices-system-image:
milestone: ww05-2015 → ww07-2015
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package thumbnailer - 1.3+15.04.20150122-0ubuntu1

---------------
thumbnailer (1.3+15.04.20150122-0ubuntu1) vivid; urgency=low

  [ Florian Boucault ]
  * Keeps track of failed thumbnails and do not try to regenerate them.
    (LP: #1389678)
  * QML thumbnail provider: make sure sourceSize (aka requestedSize) is
    respected by downscaling at loading time if necessary. Makes
    TN_SIZE_ORIGINAL case much faster. (LP: #1391368)
 -- Ubuntu daily release <email address hidden> Thu, 22 Jan 2015 08:56:16 +0000

Changed in thumbnailer (Ubuntu RTM):
status: New → Fix Released
Changed in canonical-devices-system-image:
status: In Progress → Fix Released
Changed in thumbnailer:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers