← Back to team overview

touch-packages team mailing list archive

[Bug 1391368] Re: Thumbnail generation is slow when requesting a sourceSize that needs to be rescaled

 

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 <ps-jenkins@xxxxxxxxxxxxxxxxxxx>   Thu, 22 Jan 2015 08:56:16 +0000

** Changed in: thumbnailer (Ubuntu)
       Status: New => Fix Released

-- 
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/1391368

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

Status in Thumbnail generator for all kinds of files:
  New
Status in thumbnailer package in Ubuntu:
  Fix Released

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/thumbnailer/+bug/1391368/+subscriptions