per https://commons.wikimedia.org/?oldid=165672017 People want larger sizes on $wgImageLimits
This should generally not affect performance, as the larger size would only be rendered if the user specificly clicked on it. Doing
$wgImageLimits[] = array( '2048', '1536' );
$wgImageLimits[] = array( '3200', '2400' );
would probably satisfy everyone (?)
Also have to look out for $wgSVGMaxSize which is really set way too low (and has a slightly buggy implementation).
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T64559 Redesign Special:Preferences (tracking) | |||
| Open | None | T71550 Move code in enwiki MediaWiki:Common.js and Gadgets to MediaWiki software | |||
| Resolved | Jdlrobson | T8834 Add "Other resolutions"-links to .svg files as well (PNG thumbnails) | |||
| Resolved | Krinkle | T106263 Add larger sizes to $wgImageLimits on commons |
Should look like:
This image rendered as PNG in other widths: 200px, 500px, 1000px, 2000px.
Fixed width isn't helpful. It is better to provide the PNG link of the same native/nominal size as the source SVG. Also there should be a width entry box for reader to generate the link of specific size on demand instead of providing bunch of presets.
There should already be a link to the nominal size if its sane. We are not going to provide a link to the nominal size if that size is something like 100000 x 100000 pixels
Also there should be a width entry box for reader to generate the link of specific size on demand instead of providing bunch of presets.
I don't think that's a good idea from a UX perspective. I'd be opposed to doing that in MediaWiki. (Commons can of course do that in JS if they want)
There should already be a link to the nominal size if its sane.
There is never a PNG render link of the nominal size unless the SVG native size is coincidentally the same as one of the presets.
https://commons.wikimedia.org/wiki/File:$100-school-server-_NetworkView.svg - nominal size is 506 × 337 there is a link under image:
Size of this preview: 506 × 337 pixels.
This will only be true if the nominal size is less than whatever Image size limit is set to in https://commons.wikimedia.org/wiki/Special:Preferences#mw-prefsection-rendering (defaults to 800x600). Admittedly 800x600 is a little low. I suppose it might make sense to add the nominal size as an "other" resolution if it happens to be bigger than the "image size limit" but less than $wgMaxSVGSize (4096px currently).
Actually, it looks like this is only because of a typo in the source code. In principle its supposed to always display the nominal size in the list.
Slightly off topic for this bug, but the fix for that is https://gerrit.wikimedia.org/r/225688
The performance impact depends on how many people enable the new bigger sizes. If it's not many people, they will themselves experience a performance impact by having a high likelihood of triggering thumbnail generation on the fly. Although, since we currently keep all thumbnails forever, this will get better with time. And the more people use those sizes, the smaller the chance that each person will experience it individually.
There is however a financial cost to doing this. Since we currently store as many as 6 copies of each thumbnail forever (an issue we're trying to solve at the moment, but is still months away from being resolved), and since those would be large sizes, it might require extra swift capacity, and thus, an actual cost.
This would be a lot easier to accept once the production thumbnailing overhaul is done and we don't store that many copies or thumbnails, nor store them forever. I would personally recommend waiting for that to happen, since I'm working full time on this overhaul.
I totally understand the need this is coming from, and this is precisely why we're redoing the thumbnailing infrastructure. It's been very frustrating not to be able to adapt to bigger screen sizes and pixel density, etc. rapidly because of how wasteful our current setup is.
@Gilles I wonder if the software is able to detect if the specific size is actually being used in any wiki page instead of being called merely "for personal use" so the system will remove the thumbnail of the latter case to free up some space.
The current architecture doesn't allow us to detect and remove "unused" thumbnails, otherwise we would. This is we we're revisiting that whole system.
This task is indirectly blocking the removal of JavaScript code on Wikimedia Commons that has been sitting there causing issues since 2010.
It causes a flash of unstyled content on file description pages (due to inserting links late with JavaScript), and causing a general amateurish look and confusion to users due to presenting two sets of links with effectively the same purpose:
https://commons.wikimedia.org/wiki/File:Example.svg
Size of this PNG preview of this SVG file: 600 × 600 pixels. Other resolutions: 240 × 240 pixels | 480 × 480 pixels | 768 × 768 pixels | 1,024 × 1,024 pixels.
This image rendered as PNG in other widths: 200px, 500px, 1000px, 2000px.
Adding 2048 to $wgImageLimits I think is uncontroversial and imho safe to do for two reasons:
In fact, I would expect storage demand to decrease as result of this change because it means the JavaScript hack can be removed and thus we're going from presenting 8 extra size links (4+4) to presenting 5 size links. We'd pretty much remove demand for 200/500/1000/2000.
Change 680765 had a related patch set uploaded (by Krinkle; author: Krinkle):
[mediawiki/core@master] ImagePage: Add 2048px to $wgImageLimits for file description pages
Change 680765 merged by jenkins-bot:
[mediawiki/core@master] ImagePage: Add 2048px to $wgImageLimits for file description pages
Change 682645 had a related patch set uploaded (by Jforrester; author: Krinkle):
[mediawiki/core@REL1_36] ImagePage: Add 2048px to $wgImageLimits for file description pages
Change 682645 merged by jenkins-bot:
[mediawiki/core@REL1_36] ImagePage: Add 2048px to $wgImageLimits for file description pages