Hacker News Reader

Comment by golergka | Hacker News Reader

This runs slower on my computer than MGSV in ultra settings running on 4k resolution.

It’s projecting thousands of sphere geodesics at pixel precision via breaking them into a large number (hundreds of thousands?) of little line segments and evaluating several expensive nonlinear functions at each of those points with considerable Javascript dataflow overhead for each one, not to mention the cost of putting thousands of polygons with dozens or hundreds of points each into SVG.

It would take either a domain expert or someone willing to spend a few months studying the problem to write an optimized version, but then it could probably be made to run a couple orders of magnitude faster by using slightly coarser approximations for various function evaluations (no need for 10^-15 precision for drawing on screen), or by simplifying the problem to require fewer function evaluations overall (e.g. by using Bézier curve segments instead of straight line segments), rewriting the core of the library to be vectorized, and rendering via a raster- rather than DOM-based drawing system. I’m sure a GPU could handle such a problem very effectively, though working with WebGL might be a pain.

Anyway, go for it!

It runs Voronoi every step instead of building polygons once?

Why?

No it does not. Computing the spherical polygons that make up the Voronoi diagram just happens once.

The expensive part is rendering them in an arbitrary map projection.

Considering this is an orthographic projection, and therefore spherical polygon edges are all ellipses, rendering this picture could certainly be special-cased to only draw ellipses and thereby run much faster. But it’s using a very general D3-geo framework. If you want you can easily tweak the code and the map will be drawn on whatever projection you like.

To see some of the possibilities, go to http://bl.ocks.org/mbostock and scroll down a bit.

Completely unusable on my iPad Air. Damn.

It's amazing how fast computers are. And it's amazing how slow we make them with layers and layers of cruft built atop more layers and layers of cruft.

The difference is that all you have to do to view this is punch a URL into a browser, on virtually any computer in any form factor, and it's on your screen instantly with absolutely zero setup. Of course there's a performance cost to this incredible convenience.

Imagine if the author had instead used, say, DirectX and C++ and only bothered compiling it for his own platform. Not only would it be nearly impossible for this to have reached the same audience so quickly, but it likely would have taken the author longer to make as well because JavaScript + D3.js are uniquely suited towards rapidly making these sorts of prototypes.

Hmm, that's not really fair. Programmer time is a major consideration.

We live in a time where a complicated, interesting visualization like this can be built in a day or two, and appear as #3 on hacker news. Less than 10 years ago it probably would have taken 10x the time, maybe more, and your iPad Air didn't exist.

Without those layers of 'cruft' putting together something like this would involve weeks of work by a team of domain experts, rather than a few hours of work by a single person in his free time.

Hmmm, which one is the result of a team of experts competing with other major corporate entities, getting paid to optimize a set of well-known algorithms for months prior to delivery to an audience of millions who will spend thousands of hours with it and which one is a one-off hack meant to demo the first iteration of some new code for the first time on its new platform?

I know right?? It's mind-blowing! My PC can push millions (is that the order of magnitude?) of polygons per second. But it locks up an entire core to render a couple hundred polygons (plus the layers of cruft), and can't do it at more than ~10Hz.

Rendering isn't the slow part here. The projection is (and map projections are quite expensive to calculate).

It's projecting polygons/lines on a sphere (all the rest could and should be precalculated), am I missing something or how would this be expensive on a modern computer five years ago?

It's not like it's doing global illumination pathtracing or anything.

It's not smooth, but totally usable on my i7-3770K workstation.

For what it's worth, it's also fun that key elements of the text are dynamic. When I first landed on the page with noscript suppressing any script, I saw:

> Most Remote Airport

> … at … is the most remote; from the nearest airport, .

Usually if I see any text, I don't bother enabling script, so this confused me. Luckily I did enable the script and then saw the principle UI element on the page. :)

What's really needed is an OpenGL/WebGL implementation of D3.js

cesium.js is kinda in that direction (for the specific case of visualizations on a globe).

CPU bottleneck, not graphics card.

Of course. And JS is not a compiled language. And a language that was not created with performance in mind. I mean, I know this stuff, I can think of a lot of reason for it.

But the end result is just toooooooooo much for any reasons.

Reply on news.ycombinator.com