Page MenuHomePhabricator

Blurry SVG renderings on mobile
Closed, ResolvedPublic

Description

A few months back we started removing the srcset attribute from images on the mobile interface as a bandwidth optimization.

This is probably OK for photos, which usually look only slightly fuzzy on a 1.5x, 2x, or higher resolution mobile screen, but makes diagrams rendered from SVGs look very fuzzy. I cannot currently attach screenshots from my iPad as phab requires drag and drop. :)

We should either not remove the srcset attributes for such diagrams, or we should go ahead and pull the SVG directly if it's suitably sized.

Probably other tasks to ping on this, but I'm on slow network right now and it will take a bit to track them all down in phabricator. :)

Event Timeline

brion created this task.Apr 24 2016, 1:49 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 24 2016, 1:49 PM
phuedx added a subscriber: phuedx.Apr 26 2016, 5:14 PM
jhobs triaged this task as Low priority.Apr 26 2016, 5:14 PM

Change 286523 had a related patch set uploaded (by Brion VIBBER):
Whitelist rasterized SVG images for srcset density-responsive output

https://gerrit.wikimedia.org/r/286523

Pinging @ori & @Jdlrobson for review -- my patch for this bug whitelists '.svg.png' thumbnails to keep their srcset. These are usually icons and diagrams that should compress fairly well and benefit more than photos do from the higher resolution output.

Setting can be changed if desired to whitelist more or remove the whitelisting if we find we need to switch them back off.

Or if it's better to pull based on source file type or some other thing... need to adjust MediaTransformOutput in core to allow getting at the protected file property.

Pasting from the Gerrit patch a conversation between @brion and I:

@Jdlrobson:

I'm not sure how I feel about this.
If a page has multiple svgs then a slow connection loses the benefit of the srcset removal.

@brion: You still get the benefit of the srcset removal on all the JPEG photos. :)
We should probably do a quick survey of the file sizes for common maps & icons and whatnot to confirm or deny my hunch that they usually compress well enough at 1.5x and 2x.

Using a whitelist seems like a hacky way around this (could we not just do something like Image->isSVG?

There is file->isVectorized(), or the actual file->getMimeType to be more specific about source file type... but you can't get at MediaTransformOutput->file property currently as it's protected and not exposed via the hook. Would need to patch core to either expose the file via an accessor or on the hook.

I know a while back we considered actually embedding real SVGs in the page. I remember Ori was pushing for that but I never saw a write up explaining benefits/cons of doing so.
Is this worth reigniting?

Yes, yes, and yes. Quick summary:
upside: many SVGs are smaller than their PNG rasterizations
upside: native-resolution rendering, even on 3x and 4x displays, without further increase in file size
downside: some SVGs are actually HUGE, for instance super-detailed maps
downside: some SVGs render very slowly even if not huge, for instance with heavy filter usage
downside: browser compatibility issues
downside: difficulty in availability of fonts for text & i18n

brion added a comment.May 4 2016, 4:49 PM

@Jdlrobson found the old task for direct usage of SVG: T5593

Change 286523 merged by jenkins-bot:
Whitelist rasterized SVG images for srcset density-responsive output

https://gerrit.wikimedia.org/r/286523

Jdlrobson closed this task as Resolved.May 27 2016, 10:01 PM
Jdlrobson claimed this task.