Hacker News Reader

Comment by ridiculous_fish | Hacker News Reader

> and quantum physics

Hmm. I built the first version of my quantum wavefunction visualizer with D3, since D3 has a reputation for being good at visualization. However I eventually dropped D3 for WebGL-backed three.js.

One problem is much of the SVG spec is just not implemented. This means it is less capable than it appears at first. 3D in particular was very awkward.

Performance was also a problem. D3 round trips through text, making it hard to achieve fast custom animations. A big performance win was to truncate floats to two decimal places, which is an absurd thing to need to do.

three.js had its own issues, in particular drawing lines which is quite challenging. However it was more flexible and faster.

http://ridiculousfish.com/wavefiz/ if anyone wants to see.

View on HN

By the way you might enjoy this new book, https://people.maths.ox.ac.uk/trefethen/ExplODE/

And more generally, http://www.chebfun.org

e.g. http://www.chebfun.org/examples/ode-eig/DoubleWell.html http://www.chebfun.org/examples/ode-eig/Eigenstates.html

> D3 round trips through text, making it hard to achieve fast custom animations.

Isn’t this just an inherent problem with using SVG (or DOM in general)?

Conceivably you could use D3 to drive some other drawing method, though you might not get that much out of it at that point, unless you were trying to draw maps or something.

I think the answer is no; for example one can use document.createElement(). I found that D3 was doing the equivalent of setting innerHTML.

Not sure about current browsers, but a few years ago setting innerHTML was significantly faster than the other DOM APIs.

But in any event SVG path strings (and other element attributes) are inherently strings, there’s nothing you can do to get around that.

three.js is faster?? That's nuts that the gpu accelerated shader pipeline are more performant than rendering a DOM.

Why is that nuts?

GPUs are special-purpose hardware designed explicitly for tasks like rendering graphics, and WebGL is based on a version from the late 2000s, based on insights from generations of high-performance computer games.

SVG is an XML-based bureaucratic-committee-specified document format from the late 1990s with a bunch of weirdly designed graphical elements thrown in, largely based on a drawing model invented in the 1970s.

Because the up front costs of initialization and loading data into and out of the pipeline shaders are significant. Once loaded stuff is much faster but the linked page has a pretty simple graph, not a complex 3d rendered scene. One would assume it would be faster to load a simple DOM then spin up a 3d renderer for the same amount of work.

Both WebGL viz and the browser ultimately go through a pipeline to the screen. If you do GL, you can skip the cruft, e.g., SVG middleware. I've been surprised when SVG would seem ok... And we ended up getting big slowdowns and glitches, and ended up rewriting in GL.

SVG was mostly created by Adobe to establish an in-browser vector graphic model, based on their extensive experience in PDF. Once Adobe bought Macromedia/Flash around 2003 or so, they mostly lost interest in it for a while.

SVG2 is/was an initiative to modernize it (and is to be finalized these days based on actual implemented features) but browser vendors have indicated they're only implementing a small set of conservative features [1] considering many vector effect features for UI are already part of CSS.

When SVG2 is finalized, it will probably just consist of a description of those SVG 1.1 and 1.2 feature actually implemented in browsers.

[1]: https://nikosandronikos.github.io/svg2-info/svg2-feature-sup...

SVG 2 adds a big pile of stuff, some of which seems completely unnecessary to me, https://github.com/w3c/svgwg/wiki/SVG-2-new-features

But it doesn’t fundamentally change the concept, which as I said is to be a 1990s-style XML-based document format with a bunch of (frankly inconsistent and arbitrary) graphical elements in it, based on a 1970s drawing model. YMMV.

It’s great that it exists because browsers don’t give web authors any alternative method to match many of its capabilities. But it’s just as much of a confusing and frustrating mess as all the other web specs.

You keep repeating the "70s/90s" rant, but what's your recommendation to web authors for vector graphic content such as diagrams, maps, content in education, etc. that doesn't become obsolete when your JavaScript lib is superseded by the next one?

They should absolutely use SVG for this.

The browser doesn’t have any better way to do it. The performance will likely be good enough for whatever they are trying to do; CPUs are super fast these days, and can render many thousands of graphical elements at 60 frames per second even if you are forced to render everything in a cache ignorant and super-high-overhead roundabout fashion, and could conceivably do it all 20x more efficiently on bare metal on the CPU, or 1000x faster on a GPU.

If performance turns out to be unusably slow, they’re basically screwed, because the alternative (writing some WebGL thing from scratch) is way way harder.

There are a bunch of inherent graphical problems baked into SVG implementations (like compositing done in the wrong color space, lack of support for reasonable color spaces, inaccurate rendering of very fine features, phantom rendering of hairline gaps between immediately adjacent shapes, poor text layout, many components which are too inflexible to handle straight-forward goals, weird inconsistencies with other common tools, various bugs and cross-implementation incompatibilities, etc. etc.) but implementing a whole vector graphics pipeline from scratch to fix those would take years of work from a team of experts, something akin to implementing a video game rendering engine.

Someone just trying to make diagrams should live within the constraints of SVG and try to be happy with what it is, maybe with occasional grumping on a web forum.

Any other D3 performance hacks?

Reply on news.ycombinator.com