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_River_Styx.jpg/300px-Crossing_the_River_Styx.jpg" 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/abafedb99d571cf9dec30d1695e1044a1a78ca14/resources%2Fext.popups.core.js#L161

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 <psaxena@wikimedia.org> 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/abafedb99d571cf9dec30d1695e1044a1a78ca14/resources%2Fext.popups.core.js#L46

_______________________________________________
Multimedia mailing list
Multimedia@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia