Page MenuHomePhabricator

ForeignAPIRepo / InstantCommons should fetch multiple-density thumbnails in one request
Open, MediumPublic


To support high-density displays, we generate or fetch media thumbnails at three resolutions: standard 1x, 1.5x, and 2.0x density.

When going over InstantCommons, this currently requires us to make three separate thumbnail lookups over the internet, which are done in serial and together make for a large latency in end-user response.

If support for requesting multiple thumbnail sizes at once is added to the imageinfo API (T56035: API imageinfo should allow fetching multiple thumbnail sizes), we should be able to use that in ForeignAPIRepo (aka 'InstantCommons') to fetch the URLs for the three densities in one HTTP request. This would reduce the round-trip time for third-party users of InstantCommons.

Version: 1.22.0
Severity: normal



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 2:09 AM
bzimport set Reference to bz54037.
bzimport added a subscriber: Unknown Object (MLST).
Krinkle set Security to None.
Krinkle removed a subscriber: wikibugs-l-list.

Apparently, InstantCommons already has all the repository information configured (according to T190576 this is what gets configured):

>>> $wgForeignFileRepos
=> [
       "class" => "ForeignAPIRepo",
       "name" => "wikimediacommons",
       "apibase" => "",
       "url" => "",
       "thumbUrl" => "",
       "hashLevels" => 2,
       "transformVia404" => true,
       "fetchDescription" => true,
       "descriptionCacheExpiry" => 43200,
       "apiThumbCacheExpiry" => 0,
       "directory" => (takes the $wgUploadDirectory value)
       "backend" => "wikimediacommons-backend",

When a page contains images not in the local repository, it should perform only one request to the foreign repo with action=query&prop=imageinfo and the list of file titles that are not found on the local repo, to get image dimensions and other possible metadata, but not thumbnail URLs. It has thumbUrl in the configuration, and MediaWiki should be able to infer the URL of any thumbnail.

You cannot reliably infer thumbnail URLs, in some edge cases they depend on what MediaHandler::mustRender() would return for the file, and that cannot be determined from metadata alone. Also thumbUrl doesn't really tell you the thumbnail URL structure.

I think $wgForeignFileRepos has all the information to determine the thumbnail URL structure. It would need to configure something like a LocalFileRepo but with the remote url. hashLevels would be used to generate the hash levels, and thumbUrl would be used for thumbnails. This should work for InstantCommons. If other repositories have some special handling, they would need to subclass ForeignAPIRepo.

You're right about MediaHandler::mustRender(). This can be a flag that may be added to the results of action=query&prop=imageinfo to allow this special handling.

You'd have to deal with changing the file extension for things like SVG, with max filename length, and who knows what else. Seems like a ton of effort just to work around the API not being able to handle multiple sizes. And images are not even guaranteed to exist on the remote repo in the given size until you query them.