Page MenuHomePhabricator

Pages should use downsized / thumbnail versions of embedded animated .gifs (animations/gifs don't play as they exceed wgMaxAnimatedGifArea and/or cause unnecessary load)
Open, Needs TriagePublic

Description

I uploaded this animation and tried adding it to this article but the animation did not play despite only being the small thumbnail version (I used the "thumb" parameter).

On the file's pages (Commons and WP) it only displayed: ''Note: Due to technical limitations, thumbnails of high resolution GIF images such as this one will not be animated.'' which was not helpful for solving this problem and I couldn't find any help page with information that helps solving this. If there is a help page for animations please link it here - otherwise the creation of such a page would be needed as well.

In this discussion I learned about the width × height × framerate × seconds < 100 million limit for animations and that apparently currently the short-term solution to this is a making a separate upload with a smaller version.

Could pages please use the downsized / thumbnail version below that limit? Just like with images, pages don't need to use the full-sized .gif when the animation is displayed in a smaller size on it.

I haven't checked if pages really use the largest version of the gif but implementing or improving downsized embeddment of animations would bring benefits of reduced server-load and/or better media-quality and/or better media-load-speed/bandwidth-usage.

  • It looks like the smaller versions of the animated .gif file that are automatically rendered (linked at the file on Commons next to "Other resolutions:") are not animated and hence can't be used in pages that embed the animated gif: so the first step would be automatically creating animated downsized versions of the animated gifs (making sure that the downsized versions are animated if the file is an animated gif).
  • When the automatic rendering has been adjusted the thumbnail / size-specifications of embedded animated gifs may need to be adjusted as well so that they use the smaller (downsized) renderings instead of the full-sized version.
  • Once this has been done, adherence to the mediawiki-limit of $wgMaxAnimatedGifArea=100 million could be automatically implemented for embedments if they exceed that limit: either by e.g. automatically changing the size for it to be the maximum animatedgifarea or by including a downsized render just below this limit in the automatic renderings ("Other resolutions:").

Lastly, it would be nice if one could embed WebM files as animations like gifs with some parameter (so that one does not has to click the play button and the animation automatically plays in a loop). That would be a separate issue though and may or may not be related to this issue.

Event Timeline

There has been some limit since 2008 in https://www.mediawiki.org/wiki/Manual:$wgMaxAnimatedGifArea

MediaWiki:File-no-thumb-animation-gif says:

Note: Due to technical limitations, thumbnails of high resolution GIF images such as this one will not be animated.

I have requested a more helpful message at https://commons.wikimedia.org/wiki/MediaWiki_talk:File-no-thumb-animation-gif#Request_to_link_documentation_and_specify_limit

It would be better if the message was passed the value of $wgMaxAnimatedGifArea, and maybe also the calculated value for the viewed file. According to a 2012 post on the linked talk page, the message cannot add a category. If this is still the case then it would also be nice to get that ability.

On Wikimedia sites, thumbnailing (including of animated GIFs) is handled by Thumbor, independently of MediaWiki. While Thumbor's MAX_ANIMATED_GIF_AREA and MW's $wgMaxAnimatedGifArea are currently the same, they are configured independently.

The maximum area exists for two reasons:

  1. We don't want to serve huge files. Moderately-sized GIFs can have huge file sizes when animated. Basing the max area on the requested size would not have a huge impact here.
  2. GIFs are resource-intensive and latency-intensive to render. This is why the animated GIF limit was first introduced (rSVN42058). We do have better infrastructure with resource limits now, so this isn't as big a concern as in 2008, but it is still a factor. Basing the max area on the requested size would impact this factor, but I don't know how significant it would be. Someone with more experience with gifsicle may have a better answer.