Currently mediaview uses [ 320, 800, 1024, 1280, 1920, 2560, 2880 ]
This creates many thumbnail options, generating separate files for different users including for preloaded thumbnails.
This is a bit of a waste. Time to generate the thumbnail is a much more critical metric than download bytes, 14 years after this was originally implemented.
Browsers are much better at scaling and we probably just don't need this many bucket sizes.
Proposal is to set it to [ 500, 960, 1280, 2560 ] (updated from discussion, and again after confirming wgThumbnailSteps prefers 500 over 400)
We can do this via the config variable wgMediaViewerThumbnailBucketSizes after T269987 was deployed.
- Note: Previously this got reverted because of the ways arrays in mediawiki/config operate - it was merging arrays rather than otherwirting. Make sure you update wgMediaViewerThumbnailBucketSizes to use merge_strategy provide_default (by default arrays are merged via + operator). Alternatively define the config in CommonSettings.php rather than InitialiseSettings.php
- Agree on bucket values: [400, 960, 1280, 2560]
- deploy to group0 and pilot wikis - config patch
- deploy to group1
- deploy to group2
- reconciled the smallest size with wgThumbnailSteps by changing 400 to 500
QA notes
Test procedure once deployed to group0:
- make browser window very big
- go to https://test.wikipedia.org/wiki/Image-bucket-test#/media/File:File,_Asu%C3%A1n,_Egipto,_2022-04-01,_DD_142.jpg
- right-click and copy the URL of the big image -- it should be either 500px, 960px, 1280px, 2560px, not some other size
- resize the browser as small as it will go and hit reload
- right-click and copy the URL of the big image -- it should be either 500px, 960px, 1280px, or 2560px, not some other size
(Have pushed to all groups in production by now and updated to final sizes.)