Page MenuHomePhabricator

MMV lacks support for HiDPI displays
Closed, DuplicatePublic


Given that the whole point of having something like this is to improve handling across different devices (something file: pages don't do much with), MMV should really support HiDPI.

Event Timeline

HiDPI means higher pixel density, which means more pixels, which means
you need larger (higher-resolution) versions of the image. These need to
be offered alongside the regular (src) in order for them to appear
properly on higher-resolution screens. There are no high-resolution
versions (srcset) of the images served. It only serves low-res (src).

MediaWiki normally handles this by including a srcset along with the
src, but mmv appears to have bypassed (or skipped part of) the usual
image rendering.

I'm not going to explain exactly how to use this correctly as I don't
know off the top of my head, but I'm pretty sure this, at least,
actually is documented.

I know what HiDPI means (and if I did not, I could Google it), I am just not sure what specific features you are missing. srcset does not make sense for script-generated images where you can just check device capabilities and set the source URL based on that.

In the future, please be more specific as to what exactly you want
specified, as I was a bit confused. I mean there apparently isn't any
support, or if there is, it isn't working, at least in firefox. On a
hidpi display, it got blurry images from mmv, images that rendered fine
everywhere else, and with the normal file pages. Normal mw approach is
to use a srcset, generated by the file renderer. Given that this already
exists and solves the problem, it makes a lot more sense than
reinventing the wheel to implement a different solution.

PHP logic to generate srcsets is not particularly useful for a client-side application. (Also it's disabled on mobile.) And in any case srcset is a way to provide all URL for every type of display that the given piece of HTML might be applied to, so that there is no need to split the cache on device type. Using that when we already know what kind of device the HTML is generated for seems a bit silly.

If you see something that works poorly, please give proper reproduction steps. (That's usually what people mean when they ask you to be more specific on a bug report :)

dr0ptp4kt moved this task from Backlog to Needs Analysis on the MediaViewer board.
dr0ptp4kt subscribed.

It appears that the JavaScript frontend code inside of MediaViewer is attempting to leverage HiDPI where appropriate. For example, on a 13" 1440px wide HiDPI device, renders a 2880px wide image.

@Isarra, I'm thinking to mark resolved as from a UX perspective it seems to be working. Make sense?


Does not render correctly on 1.5ppp firefox. Results in a blurry image.
Interestingly, there's a flash where the image initially does appear
sharp, before being replaced with the blurry version.

This may be an issue specific to svgs.

MMV does not realize SVGs can be scaled beyond their nominal size (that's T71237; it's labeled easy but might not be). Doesn't explain the blur though; that's some problem with the placeholder image (which is intentionally blurry but should go away as soon as the large image is loaded) that might or might not be HiDPI-related.

Just noting I see the responses. Yeah, that dithering-like effect, I'm not sure what's going on. I tried throttling the connection to see if there was something in particular I could visually observe easily. That didn't help a whole lot (I guess I could record a video, but am a bit strapped for time right now and will be unavailable until sometime next week after getting caught up with email).

But something peculiar I noticed was there were a couple images involved in the network transfer, and surprisingly they didn't look even remotely the same! I don't know if the different images are resulting in this dithering-like thing and there's something about the images returned from the backend.

Do you observe a visual difference from your end at those URLs and see in your network inspector that they're both being requested? I've attached them in case there's something going on with a cache somewhere (as opposed to some sort of masking layer or something in the source image) along the way and you can't reproduce that.

350px-Wikimedia_beetle.svg.png (350×350 px, 78 KB)

Wikimedia_beetle.png (449×530 px, 262 KB)

Wikimedia_beetle.png and Wikimedia_beetle.svg are different images. One of them is probably being preloaded.

Oh right, it's one of the "other versions" popping in on the main File: page itself...well, so probably not that.