Page MenuHomePhabricator

Replace static images with full client-rendered graphs
Closed, ResolvedPublic


(Link to previous discussion.)

Small effects like "hover" and larger effects for full interactivity only work when the graph is rendered on the client, which requires loading the d3 and vega libraries, along with external data needed by the graph, which slows things down significantly. One possible solution to this is to first load just the static image from the server, and then replace it with the full interactive graph afterwards. One downside of this would be using up a substantial amount of bandwidth. (Presumably, the libraries would be cached, but the graph data wouldn't be, right?)

Currently, basic graphs only load static images, except on preview. Interactive graphs only load interactivity after the viewer presses the "play" button/"interactable" icon.

Event Timeline

Yair_rand raised the priority of this task from to Needs Triage.
Yair_rand updated the task description. (Show Details)
Yair_rand added subscribers: Yair_rand, Yurik.

I wonder if we should do this for desktop only, basically assuming that "desktop" means faster unmetered network. @ori, do we have a reliable way to detect when its ok to download extra data, or when it should be "on demand"?

@ori: Is there a reliable way to detect when its ok to download extra data, or when it should be "on demand"?
(Repeating @Yurik's question here.)

do we have a reliable way to detect when its ok to download extra data, or when it should be "on demand"?

No, not right now and unlikely for the foreseeable future. I would recommend against loading the client-side rendering by default on page views with graphs. However we can lazy-load it based on user interaction. The "play" button is a good start and seems to work well. This could be extended and integrated further to feel more seamless for the user. I imagine the current play button may feel like a boundary that makes interaction less likely, indeed.

PS: It seems mode=interactive doesn't work on

It is now four years later and bandwidths have increased. How much of an issue is the overhead these days? I am sorry that I do not know how to measure this myself. I would really like the graphs on Wikipedia to look nicer and more similar to the rest of the Web.

If we do not want to have client-rendered graphs throughout, would it then perhaps be possible to publish a PNG file that looks as nice as the SVG file in the preview? Looking here for instance, the graphs are noticeably blurry, in particular al the numbers on the axes are blurred. But in preview mode, they look fine! I do no understand why the final PNG should look so much worse; just taking a screenshot and publishing that would give much nicer results.

Another option could be to let users choose what kind of graphs they want to see in their general settings.

@KarlFrei actually that might be happening later this year: T236892 mostly because the graphoid service is lacking maintainers.

The current graph rendering looks blurry on most displays as most displays are now "HiDPI" displays (more dots per inch, eg. 2x2 dots per virtual pixel is common).

For SVG PNG and JPEG images from Commons, MediaWiki renders its thumbnails at 2 dppx (2x), which is why those look sharp. If Graphoid were configured to also render at 2x, they would look sharp again as well. This isn't due to whether it renders a PNG or with JS.

Apparently this is now resolved.

Yes, I believe so. Anyone please re-open if you disagree.

Just curious, which patch fixed this?

All graphs are rendered client side now, since graphoid was undeployed (via a series of patches over a long-ish time). Graphoid not existing is not ideal for a number of reasons, but it does indeed "solve" this problem :)