4 ms·

> 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.

> 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/ http://ridiculousfish.com/wavefiz/ if anyone wants to see.

bordercases 8y ago
Any other D3 performance hacks?
jacobolus 8y ago
> 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.
- ridiculous_fish 8y ago
  I think the answer is no; for example one can use document.createElement(). I found that D3 was doing the equivalent of setting innerHTML.
  - jacobolus 8y ago
    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.
iopuy 8y ago
three.js is faster?? That's nuts that the gpu accelerated shader pipeline are more performant than rendering a DOM.
- jacobolus 8y ago
  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.
  - iopuy 8y ago
    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.
    - lmeyerov 8y ago
      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.
  - tannhaeuser 8y ago
    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-support/ https://nikosandronikos.github.io/svg2-info/svg2-feature-sup...
jacobolus 8y ago
By the way you might enjoy this new book, https://people.maths.ox.ac.uk/trefethen/ExplODE/ https://people.maths.ox.ac.uk/trefethen/ExplODE/ And more generally, http://www.chebfun.org http://www.chebfun.org e.g. http://www.chebfun.org/examples/ode-eig/DoubleWell.html http://www.chebfun.org/examples/ode-eig/DoubleWell.html http://www.chebfun.org/examples/ode-eig/Eigenstates.html http://www.chebfun.org/examples/ode-eig/Eigenstates.html

bordercases 8y ago

Any other D3 performance hacks?

jacobolus 8y ago

> 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.

ridiculous_fish 8y ago
I think the answer is no; for example one can use document.createElement(). I found that D3 was doing the equivalent of setting innerHTML.
- jacobolus 8y ago
  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.

iopuy 8y ago

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

jacobolus 8y ago
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.
- iopuy 8y ago
  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.
  - lmeyerov 8y ago
    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.
- tannhaeuser 8y ago
  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-support/ https://nikosandronikos.github.io/svg2-info/svg2-feature-sup...

jacobolus 8y ago

By the way you might enjoy this new book, https://people.maths.ox.ac.uk/trefethen/ExplODE/ https://people.maths.ox.ac.uk/trefethen/ExplODE/ And more generally, http://www.chebfun.org http://www.chebfun.org e.g. http://www.chebfun.org/examples/ode-eig/DoubleWell.html http://www.chebfun.org/examples/ode-eig/DoubleWell.html http://www.chebfun.org/examples/ode-eig/Eigenstates.html http://www.chebfun.org/examples/ode-eig/Eigenstates.html