4 ms·

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

by iopuy 8y ago

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
    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 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.
    - tannhaeuser 8y ago
      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?
      - jacobolus 8y ago
        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.

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

by iopuy 8y ago

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.

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
  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 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.
  - tannhaeuser 8y ago
    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?
    - jacobolus 8y ago
      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.