Requests for comment/Standardized thumbnails sizes

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.

Possible solution
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).

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 ...