* There's no indication of overlay loading (on Multimedia roadmap).

We have no plans for that AFAIK.

I think Juliusz means #248


On Sat, Mar 1, 2014 at 6:01 AM, Gergo Tisza <gtisza@wikimedia.org> wrote:
Hi Juliusz,

On Fri, Feb 28, 2014 at 5:31 PM, Juliusz Gonera <jgonera@wikimedia.org> wrote:
* jquery.throttle-debounce - make sure that events fire only once, needed?

It is used for rapid-fire events such as mousemove or scroll. Mobile doesn't have either, so not needed there. (Not much of a difference though - the library is 0.7K when minified.)
 
* jquery.color - what for? can we use CSS transitions?
* jquery.colorUtil - what for? can we use CSS transitions?

Dependencies for doing color transitions with jQuery.animate(). Probably can be replaced with CSS; I'll look into that when I have some free time. At any rate, .animate() still runs without those files (just doesn't produce any visible effect) so they can be omitted.
 
* moment

Used for date localization. Moment is heavy (25K minified) but the browser's built in date formatting is very unreliable.
Might be possible doing this on the server side, although it would be ugly from an API design point of view.
 
* There's no indication of overlay loading (on Multimedia roadmap).

We have no plans for that AFAIK. 
 
* Why do we load both 640px and 1920px version of images?

We preload the fullscreen version of the image. We didn't make that configurable, but we should.
 
* What is loaded at the end apart from images (+2.3MB, images are ~1MB)?

Probably more preloading? We do a lot of that. You can set mw.mmv.mediaViewer.preloadDistance = 0 to  disable. (This only works once you have opened some image already as mw.mmv.mediaViewer is created when the main JS lib is loaded; we don't have a lazy-loading compatible way to configure the viewer yet. Created #275 about that.)

Also, we request every image twice to get certain performance metrics; this should not result in the image actually being downloaded twice (although we did not test that in mobile browsers), but might confuse the network stats in Chrome. Probably also something that we should make configurable :-)

The big win in terms of size would be to make the UI modular and configurable, so you can request a MultimediaViewer instance which does not have most of the information on the metadata panel, for example, and the related files would not be loaded. We have some vague plans about that, but nothing specific yet.

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