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/abafedb99d...
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/abafedb99d...
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.orgwrote:
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 -
- Some images are taking too long to load [3]
- 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/abafedb99d...
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
I remember the reasoning for it (300px) but just forgot who told me. The error that you are pointing out is also documented [1] and has a patch [2] awaiting review.
In the bug that I had mentioned [3] the image loads just after a very long time. Are you sure that it takes only an extra second? What is the effective delay for the user? Could it be more?
I would imagine the answer is in PageImages, which I'm unfamiliar with. Have you tried contacting Max, who wrote it, about this issue?
I haven't yet, I'll talk to him soon, thanks!
--prtksxna
[1] https://bugzilla.wikimedia.org/63207 [2] https://gerrit.wikimedia.org/r/#/c/121607/ [3] https://bugzilla.wikimedia.org/63156
In the bug that I had mentioned [3] the image loads just after a very long time. Are you sure that it takes only an extra second? What is the effective delay for the user? Could it be more?
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 Fri, Mar 28, 2014 at 10:36 PM, bawolff bawolff+wn@gmail.com wrote:
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.
I have never experienced this issue myself. Is there a list of images that haven't been converted to thumbnails yet. I could create test pages that link to it and measure performance on developer tools.
On Fri, Mar 28, 2014 at 10:36 PM, bawolff bawolff+wn@gmail.com wrote:
Once lots of people use your tool the issue should go away due to varnish and swift caching of thumbs.
That is very reassuring. Could you please leave this as a comment to the bug?
--prtksxna
On Mar 28, 2014 2:12 PM, "Prateek Saxena" psaxena@wikimedia.org wrote:
On Fri, Mar 28, 2014 at 10:36 PM, bawolff bawolff+wn@gmail.com wrote:
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.
I have never experienced this issue myself. Is there a list of images that haven't been converted to thumbnails yet. I could create test pages that link to it and measure performance on developer tools.
On Fri, Mar 28, 2014 at 10:36 PM, bawolff bawolff+wn@gmail.com wrote:
Once lots of people use your tool the issue should go away due to
varnish
and swift caching of thumbs.
That is very reassuring. Could you please leave this as a comment to the
bug?
--prtksxna
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
On Fri, Mar 28, 2014 at 10:58 PM, bawolff bawolff+wn@gmail.com wrote:
I suspect something else is going on.
Me too, just commented on the bug. I think this might be a duplicate of another bug that has a patch.
--prtksxna
Prateek Saxena, 28/03/2014 18:12:
I have never experienced this issue myself. Is there a list of images that haven't been converted to thumbnails yet.
https://commons.wikimedia.org/wiki/Special:NewFiles?showbots=1&limit=50
Nemo
On Fri, Mar 28, 2014 at 10:12 AM, Prateek Saxena psaxena@wikimedia.orgwrote:
I have never experienced this issue myself. Is there a list of images that haven't been converted to thumbnails yet. I could create test pages that link to it and measure performance on developer tools.
You can load the file description page with an action=purge URL parameter, that will delete all thumbnails of that image and they will have to be re-rendered the next time you look at them. (Or you can just change 300px to 299px which is probably not used anywhere so all images will have to be rendered when you first open them.)
On 14-03-27 10:46 PM, Prateek Saxena 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.
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.
We are facing two problems with this approach -
- Some images are taking too long to load [3]
- 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/abafedb99d...
I mentioned a vague recollection of the Multimedia team wanting to pre-render a bunch more image sizes by default
Can't be done at the moment because Ops doesn't have the capacity yet. They have an ongoing hardware order that will let them increase varnish capacity and let us prerender some sizes in the future.
On Fri, Mar 28, 2014 at 7:38 PM, Quiddity pandiculation@gmail.com wrote:
On 14-03-27 10:46 PM, Prateek Saxena 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.
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_sizes ) 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.
We are facing two problems with this approach -
- Some images are taking too long to load [3]
- 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
On Fri, Mar 28, 2014 at 11:23 PM, Gergo Tisza gtisza@wikimedia.org wrote:
You can load the file description page with an action=purge URL parameter, that will delete all thumbnails of that image and they will have to be re-rendered the next time you look at them. (Or you can just change 300px to 299px which is probably not used anywhere so all images will have to be rendered when you first open them.)
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 pandiculation@gmail.com wrote:
You and Jorm and I had discussed using 220px. You mentioned this patch's comment as the reason to use 300px https://gerrit.wikimedia.org/r/#/c/109878/22/js/popup.js
What dark magic was used to obtain this information? Teach me, master.
On Sat, Mar 29, 2014 at 12:08 AM, Quiddity pandiculation@gmail.com wrote:
Unless/until the vast majority of our images are thumbnailed at 300px, I'd recommend using 220px in Hovercards.
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
multimedia@lists.wikimedia.org