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 <psaxena(a)wikimedia.org>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
