On 27 Jun 2015, at 13:36 , Victor Thompson <[email protected]> wrote:
> Have there been any recent changes to the silo? Testing looked good > the last time I personally checked, if there are deltas let me know > and I'll test as well. The main delta is that, on Arm, we are now limiting the number of concurrent gstreamer pipelines to 1 because anything else is too risky. On other architectures, we use as many gstreamer pipelines as there are CPU cores. You should see around 780% CPU utilization on an 8-core machine with heavy workloads, such as thumbnailing a whole bunch of videos at once. Once the cache is hot, it delivers the thumbnails *very* fast. Please test your applications not only with a cold cache, but also a hot one; the way memory allocations happen is markedly different that way. If you want to clean the cache and start afresh, just run thumbnailer-admin clear That wipes the cache completely. You can see cache statistics by running thumbnailer-admin stats -v Please keep an eye out for requests with an invalid QSize (width or height == -1). Get rid of all of these. Instead, ask for the thumbnail in the size you need it. This drives the cache in the most efficient way possible. Your application must be prepared to handle a smaller thumbnail than what it asked for because we never up-scale. If original artwork is available only as 512 and you ask for 640, the actual thumbnail you get will be 512. You are guaranteed that you will never get something larger than what you ask for, unless you ask for (0,0), in which case we deliver full size. (Don't do this unless there is a good chance that you will need the same image again shortly; otherwise, it just eats space in the cache and makes it less effective.) Cheers, Michi. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
