Hi Prateek, mentioned that it would be faster if it were 300. The reason why 300 is a better choice is that it's more likely to already be generated, because 300 is the default size of thumbnails. Thus, the probability that requesting a 300 thumbnail for the first time is faster than requesting a 290 (non-standard size) thumbnail is much higher. Which is why requesting a 300 thumbnail is faster on average. However, not all files have been used as thumbnails of the default size yet, which means that when a person is the first to view a hovercard for a file like that, the 300 thumbnail is generated on the fly. 1. Some images are taking too long to load [3] There's a small chance that the 300 thumbnail for a given image hasn't been generated yet. In which case the image will take on average (based on our Media Viewer performance measurements) 1 extra second to load. Once one person has seen that hovercard, though, that extra second won't happen again for anyone. If you're seeing a hovercard where a specific image is always slow, this is unlikely to be the source of the issue. I went to the Monet page and tried that specific hovercard and I couldn't get the image to show up at all. But, looking at Firebug I clearly saw that the image loaded correctly. Therefore, I think the issue appearing on that specific hovercard is something to do with Popups' code, not the thumbnail infrastructure. The image is being loaded, but it's not being displayed on the hovercard. I investigated further and found the cause of the issue: for that particular image the "y" parameter of the <image> inside the <svg> has the wrong value (186): <svg xmlns="http://www.w3.org/2000/svg" viewBox="200" width="303" height="186"><image class="mwe-popups-is-not-tall" xlink:href=" https://upload.wikimedia.org/wikipedia/commons/thumb/1/1b/Crossing_the_Rive… clip-path="url(#mwe-popups-mask)" x="0" y="186" width="300" height="186"/></svg which places the image outside of the mask, making it invisible. If I manually set "y" to 0, for example, the image appears in exactly the spot where it should be. So the bug comes from that line in your code: http://git.wikimedia.org/blob/mediawiki%2Fextensions%2FPopups.git/abafedb99… The right part of the ternary operator, "thumbnail.height" is probably incorrect, I think it should be 0. Line 135 is probably also affected. This bug happens for any 300 thumbnail which is less than 200px tall on a browser capable of svg. 2. Sometimes the first relevant image is not picked up [4] I would imagine the answer is in PageImages, which I'm unfamiliar with. Have you tried contacting Max, who wrote it, about this issue? On Fri, Mar 28, 2014 at 6:46 AM, Prateek Saxena &lt;psaxena(a)wikimedia.org&gt;wrote;wrote: > The design team recently deployed the Popups[1] extension to English > Wikipedia as a Beta Feature. We are using the PageImages[2] extension > to get a thumbnail with a `pithumbsize` of 300. This was initially > 290, but someone on IRC - I forget who - mentioned that it would be > faster if it were 300. > We are facing two problems with this approach - > 1. Some images are taking too long to load [3] > 2. Sometimes the first relevant image is not picked up [4] > Any ideas on how these bugs could be resolved would be helpful. The > code for the current implementation can be found on git [5]. > --prtksxna > [1] https://www.mediawiki.org/wiki/Extension:Popups > [2] https://www.mediawiki.org/wiki/Extension:PageImages > [3] https://bugzilla.wikimedia.org/63156 > [4] https://bugzilla.wikimedia.org/63177 > [5] > http://git.wikimedia.org/blob/mediawiki%2Fextensions%2FPopups.git/abafedb99… > _______________________________________________ > Multimedia mailing list > Multimedia(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/multimedia

How long would depend on the image. For example really big images take slightly longer. But 1-2 seconds sound rightish to me. Firebug should be able to give you how long it takes the image to load. Once lots of people use your tool the issue should go away due to varnish and swift caching of thumbs.

On Mar 28, 2014 2:12 PM, "Prateek Saxena" &lt;psaxena(a)wikimedia.org&gt; wrote: varnish bug? Oh i didnt realize the delay was 15 seconds, thats an insane amount of time for most (maybe some obscure types in edge cases might take that). I suspect something else is going on. -bawolff

Prateek Saxena, 28/03/2014 18:12: https://commons.wikimedia.org/wiki/Special:NewFiles?showbots=1&limit=50 Nemo

On 14-03-27 10:46 PM, Prateek Saxena wrote: You and Jorm and I had discussed using 220px (which is the MediaWiki default, per https://bugzilla.wikimedia.org/show_bug.cgi?id=21117 and per https://www.mediawiki.org/wiki/Requests_for_comment/Standardized_thumbnails… ) You mentioned this patch's comment as the reason to use 300px https://gerrit.wikimedia.org/r/#/c/109878/22/js/popup.js I mentioned a vague recollection of the Multimedia team wanting to pre-render a bunch more image sizes by default, in the future, and suggested asking them for confirmation/details on that. Unless/until the vast majority of our images are thumbnailed at 300px, I'd recommend using 220px in Hovercards.

On Fri, Mar 28, 2014 at 11:23 PM, Gergo Tisza &lt;gtisza(a)wikimedia.org&gt; wrote: I think the purge option is better. Pushing that change will take time and add unnecessary load on the servers. I could make my observations by purging and testing. Thanks! On Sat, Mar 29, 2014 at 12:08 AM, Quiddity &lt;pandiculation(a)gmail.com&gt; wrote: What dark magic was used to obtain this information? Teach me, master. On Sat, Mar 29, 2014 at 12:08 AM, Quiddity &lt;pandiculation(a)gmail.com&gt; wrote: 220px would become too small. We are maintaining a width and font size to improve readability. As more Hovercards are shown and more images get cached we'll face this less often, thus, I am not too worried. It turned out that bug was a false alarm, the image didn't show up even after the delay due to another bug [1]. Thanks everyone for your help, this will help me test the performance of the extension. --prtksxna [1] https://bugzilla.wikimedia.org/63207