Requests for comment/Standardized thumbnails sizes

Please have a look at the talk page

Wikitext editors can have media materials rendered using any arbitrary size (the thumbnails wikitext syntax). Each different size would produce a hit to the server backend which will generate a thumbnail for that size. This requests for comment is about having a consistent set of thumbnails that are allowed to be rendered and let the client browser to do the up or down scaling.

Context
Our thumbnails system could use some improvements to better scale out and stop generating any possible thumbnail size our user might requests. For the context, the size vary according to:


 * 1) MediaWiki default (200px on most wikis)
 * 2) per user preference picked from the list set by $wgThumbLimits
 * 3) Wikitext thumb width parameter (wich can be anything)

The default value for $wgThumbLimits is :

$wgThumbLimits = array(       120,        150,        180,        200,        250,        300    );

A global default is set for users, they can override the preference by picking one of the width from the $wgThumbLimits array.

Problem
The thumb width parameter in WikiTextis free form. When a user choose a 199 pixel width, a request is made to the backend server which produce that thumbnail size. Rendering the thumbnail is CPU heavy, specially when rendering large images. That also mean that the thumbnails are hard to cache properly since we have to cache a copy of each of the sizes.

Mark Bergsma, Wikimedia caching expert, has extracted a list of thumbnail sizes requested on one of Wikimedia thumbnail cache: /thumb sizes requested.

Serving only closest match
We could instead send the closest match (ex: 200 pixels wide) and instruct the browser to scale it down to the requested format. The client scaling can be done by passing the width attribute to an   element.

To achieve that, we should choose some preferred number series so each requested size is always within X% of the available size. The Wikipedia article en:Preferred_number list several guidelines to create such a serie. We would want to use a eerie based on power of 2, making sure the sizes are dividable by 16 due to the way most image compression algorithm works.

Icons in templates and gadget interfaces (e.g. the ~ 16px icon for featured articles in the langlinks list in the sidebar and the various templates positioned on the top right of wiki pages, such as Coordinates, Good/Featured article, Wiktionary and what not). So we'd need a small size as well. (Timo Tijhof)

Anything used in CSS. Because there there is no width or size restriction. If the image is not served with the size specified in the url, it will have consequences that are unacceptable for the user interface[1]. We'd need a long migration path to make sure all those cases are migrated to one of the standard sizes, which can be very hard as it would basically require gadgets to redesign their interface completely. (Timo Tijhof).

Other strategies
A possible solution to the second part of the problem (i.e. "the thumbnails are hard to cache properly since we have to cache a copy of each of the sizes") could be a better caching strategy than simply refusing to cache non-standard sizes.

Potential thumbnail strategies:


 * Serving
 * (A) serve arbitrary sizes as requested;
 * (B) serve only preferred sizes (rounding non-standard sizes according to some algorithm).


 * Storing
 * (1) store every requested thumbnail indefinitely;
 * (2) store only preferred-size thumbnails indefinitely.


 * Caching
 * (i) retain indefinitely (ad hoc deletion);
 * (ii) periodically delete the longest-unserved thumbnails (LRU), regenerating and recaching them if re-requested.

The status quo is A.1.i. The proposal seems to be to switch to B.2.i or possibly A.2.i (I think Brion implies that A.2 is "Tim's position").

But to prevent excessive thumbnail file storage, all that is needed is a better caching strategy. "Least Recently Used" seems like a sound but simple and non-disruptive basis for predicting which thumbnails will not be requested again.

So, instead of inconveniencing users by switching serving strategy or storing strategy, why not just switch caching strategy from (i) to (ii)?

Preferred numbers
Based on some power of 2:

16, 32, 48, 64, 96, 128, 192, 256, 384, 512, 768, 1024, 1536, 2048

Multiple of 16 which are also dividable by 10:

80, 160, 240 320, 400, 480, 560, 640, 720, 800, 880, 960, 1040, 1120, 1200, 1280, 1360, 1440, 1520 ...