Last modified: 2014-10-08 00:28:42 UTC
Every distinct thumb resolution means that files have to be resized and stored, which puts extra load on scalers, media storage and caches. Currently used sizes: * 80 - search * 150 - watchlist and page preview * 180 - nearby * 320 - user profile This should be trimmed to 2 sizes: small and large.
Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1494
Makes sense. I guess 160px (for search, watchlist, page preview and nearby would make sense) and 320px for user profile would make sense. Would be good to encapsulate this in some kind of class similar to MobileUserInfo to encourage reuse and avoid this happening again. Thoughts? e.g. MobilePageInfo { function getSmallThumbnail() function getMediumThumbnail() }
(In reply to comment #2) > Makes sense. > I guess > 160px (for search, watchlist, page preview and nearby would make sense) and > 320px for user profile would make sense. These sizes should be already present from other sources eg 120, 150, 180, 200, 250 and 300 from standard thumbnail size settings or 50 from OpenSearchXml. I propose 120 for bandwidth conservation as a small image and 300 as a large. > Would be good to encapsulate this in some kind of class similar to > MobileUserInfo to encourage reuse and avoid this happening again. Thoughts? > > e.g. > MobilePageInfo { > function getSmallThumbnail() > function getMediumThumbnail() > } I don't think so because some images are requested from PHP while others from JS.
See the related RfC at: https://www.mediawiki.org/wiki/Requests_for_comment/Standardized_thumbnails_sizes
(In reply to Max Semenik from comment #3) > These sizes should be already present from other sources eg 120, 150, 180, > 200, 250 and 300 from standard thumbnail size settings or 50 from > OpenSearchXml. I propose 120 for bandwidth conservation as a small image and > 300 as a large. Why limit the sizes to two when the list you gave has more than two sizes? Out of the 4 cases you mentioned only search and user profile images need to change, right? It looks like 120 and 150 are already being generated anyway. Also, is 64 one of the sizes that's being generated already? The search could use it.
No.
Change 164622 had a related patch set uploaded by Bmansurov: Use standard image sizes https://gerrit.wikimedia.org/r/164622
I like standardizing the sizes, but I'm a bit concerned about increasing the search thumb size from 80 to 120 due to the increase in bandwidth this would create (and corresponding speed decrease on slow connections). The actual display size is only 56px and I'm not convinced we need retina support for these (since they are just for quick reference).
Change 164622 merged by jenkins-bot: Use 300px standard image size for uploads https://gerrit.wikimedia.org/r/164622
Update... We currently define small, medium and tiny image sizes const MEDIUM_IMAGE_WIDTH = 300; const SMALL_IMAGE_WIDTH = 150; const TINY_IMAGE_WIDTH = 50; User profile uses medium width watchlist uses small width nothing uses tiny width. In addition to this we have various things still not using standard sizes: * Nearby uses 180px * Search uses 80px I would suggest making nearby use SMALL_IMAGE_WIDTH and search using tiny image width and changing that value from 50 to 80. Then we should call this done.
Would it be a good idea to use some value closer to 56px (as Ryan mentioned), and not use 80px for search? Also, TINY image width is also used in less - changing its value may cause some other issues. Maybe create a new variable for search?
MM wgMFThumbnailTiny is probably being abused there. I'd suggest replacing the css rule with min-height: 50px;
Change 165408 had a related patch set uploaded by Bmansurov: Use 300px standard image size for uploads https://gerrit.wikimedia.org/r/165408
Change 165408 merged by jenkins-bot: Use standard image sizes on nearby, search and watchlist https://gerrit.wikimedia.org/r/165408
