Comment by monfera | Hacker News Reader

Comment by monfera | Hacker News Reader

Maker here. I meant it as a way of saying good-bye to SVG as for the past years I mostly work with WebGL. A couple of other bl.ocks will be up soon.

It turns out that despite its name, Scalable Vector Graphics it isn't. Sure it's scalable _spatially_ but it's not scalable _temporally_. A.k.a. slow.

SVG only recently became capable of 60FPS (with only a few elements, of course). Until this year, it was capped at ~40FPS.

Also, SVG was meant for graphics and the HTML DOM wasn't. Yet SVG transforms are NOT hardware accelerated, click on Paint Flashing in Chrome Dev Tools / Render: http://codepen.io/monfera/pen/JKOqyY Meanwhile HTML transforms are GPU accelerated: http://codepen.io/monfera/full/qNVzBm/ or http://codepen.io/monfera/full/BzmERz/ (no green rectangles flashing)

There's also a big overhead of just having a lot of SVG elements even if they're presently off-screen (in which case WebGL wouldn't draw it or even if you call gl.drawArrays on them it doesn't hit the shaders).

Having done WebGL I feel that a transpiler from SVG filters to WebGL I could hack together would be an order of magnitude (usually I get an order or two magnitude speedup when moving a plot to WebGL).

Someone at a major browser vendor confirmed there hasn't been significant work on SVG for many years. SMIL is now out. The hardware accelerated HTML DOM, Canvas and WebGL are eating SVG's lunch. I suspect it's one of the reasons the new D3 4.0 adds more separation of concern between logic and rendering, and there's a wealth of Canvas based examples from Mike Bostock and others.

To paraphrase Greenspun's tenth rule: Any sufficiently complicated Canvas/WebGL 2D data visualization contains an ad hoc, informally-specified, bug-ridden, but FAST implementation of half of SVG. And it's sent down the network each time, including mountains of font rasterization.

To what extent SVG is hardware-accelerated entirely depends on the browser. Chrome was quite late to the party of making drawing fast and it often shows (it redeems itself with a fast JavaScript implementation in complex applications that have a lot of rendering and computation). But the raw drawing (of SVG, not canvas) has been a lot faster in IE for quite a while.

I'm working on a graph drawing library at work and for our web product we rely on SVG. In my experience the performance is good enough for our purpose at least (graphs are a thing that becomes more or less unreadable as the number of entities go up, so useful graphs tend to only have a few hundred nodes/edges on the screen at most; and that's still effortlessly possible with 60 fps interaction). Where it gets annoying is that especially Google clearly doesn't really care for SVG. It's not used (much; or only with static images) in the top 500 sites or whatever they look at for optimising their browser, so they frequently break things with rendering that come to bite our customers.

Google was first with a decent SVG and they were leapfrogged. But Chrome is the most used browser, and together with Safari, WebKit leads big time over the shrinking IE and FF portion. I and my clients can't afford to do entirely different things per browser.

My area of data visualization involves e.g. time series, where a decent zoom/pan implementation and a few years of stock or weather data means that you're juggling DOM elements in and out to keep frame rate, but adding/removing DOM elements revolver style is even more expensive, introducing janks. I also tend to work on exploratory vis where it's useful to scatter all points, tween them (not as a gratuitous effect but for object constancy, to help the user keep context) etc.

Interestingly it's also Google who wants you to get minimal with payload size. Yet it's OK for them if you roll your own speedy version of SVG by bundling a 100k of three.js or make your own text rasterizer, essentially reimplementing browser functionality.

Actually, Opera was pretty much the only browser with useful SVG support for a long time. All other browsers plodded along with little more than basic shapes.

I was just in the process of converting all my .png icons into SVG. Should I reconsider this? Also, how well do other solutions work with CSS?

No, SVG is perfect for things like that, and very compact (example coming, or an existing one, check the header image on twitter/monfera). I'm mostly concerned about dynamic visualizations.

Ah, okay, thanks!

In one of my web app projects, I went the other way. I converted SVG icons to appropriately sized PNGs. That was after I found out that SVG rendering was slow on mobile, and was the culprit of janky scrolling.

Safari / Chrome don't layerize SVG content but Firefox does so you do get hardware-composited async animations when animation the transform property of SVG content in Firefox.

I'd be surprised if any browser is drawing off-screen SVG elements but perhaps some do.

Interestingly Firefox is often quite a bit slower than WebKit based browsers even if there's not much JavaScript behind the animations, so there may be other bottlenecks.

Even simple SVG geometries (e.g. line sections) take more time to render if there are lots of other such SVG elements off-screen in the DOM. The simplest thing for a time series would be putting in a bunch of <path> elements with long 'd' path strings (and annotations etc.) and just use CSS or SVG transform to show the currently interesting part, but even such a simple use case - ideal and compact from a graphics denotation viewpoint - bumps into performance constraints real quick if you want to pan or especially zoom at 60FPS. This stuff works great with WebGL so I'm coding up splines etc. which all exist in SVG - it's a great standard that would deserve a real fast benchmark and competition among browser makers.

Reply on news.ycombinator.com