Live data from Hacker News

Easy SVG sparklines

alexplescan.com

21–30 of 106 posts

Re: Easy SVG sparklines

#21
post #10

But SVG is slower than Canvas. The main use case for sparklines is embedding them into cells, many hundreds or even thousands of them [1]. With hundreds of SVG files page becomes becomes visibly slower (first paint, scroll, interactions). I suggest to invest some time and check canvas solution too. [1]: https://www.google.com/search?q=sparkline&tbm=isch

Hard to imagine that pure-HTML SVG is really slower than Canvas which relies on JS..

Canvas is faster _because_ it relies on JS. It’s a much dumber and stateful API - the browser has to do much less work.

Re: Easy SVG sparklines

#22
post #10

But SVG is slower than Canvas. The main use case for sparklines is embedding them into cells, many hundreds or even thousands of them [1]. With hundreds of SVG files page becomes becomes visibly slower (first paint, scroll, interactions). I suggest to invest some time and check canvas solution too. [1]: https://www.google.com/search?q=sparkline&tbm=isch

If pure client-side performance is key, and you can afford a little extra bandwidth, then go a little further and pre-draw server-side and transfer as date:uri images. Then you are not relying on JS running on the client to draw on the canvases. Not an option if you need things drawn more dynamically client-side, in response to user changes/filters/etc without a server round-trip, of course.

Though in any case if you have thousands of sparklines in cells I'd question if the display is actually useful to anyone.

Unless it is a large table of data you are presenting in which case thousands of rows has display time issues in my experience anyway. I have in mind a CSV preview on one of our support dashboards which takes a noticeable time to render when given a client import of ~8,000 rows and ~15 columns and that is not a lot more than a plain HTML table.

Re: Easy SVG sparklines

#23
post #10

But SVG is slower than Canvas. The main use case for sparklines is embedding them into cells, many hundreds or even thousands of them [1]. With hundreds of SVG files page becomes becomes visibly slower (first paint, scroll, interactions). I suggest to invest some time and check canvas solution too. [1]: https://www.google.com/search?q=sparkline&tbm=isch

In that case, browsers should optimize SVG more.

SVG could never be as fast as canvas.

Re: Easy SVG sparklines

#24
post #10

But SVG is slower than Canvas. The main use case for sparklines is embedding them into cells, many hundreds or even thousands of them [1]. With hundreds of SVG files page becomes becomes visibly slower (first paint, scroll, interactions). I suggest to invest some time and check canvas solution too. [1]: https://www.google.com/search?q=sparkline&tbm=isch

Of course SVG is slower than Canvas. SVG is fundamentally much more powerful. Canvas is just a pixel buffer. You know what's even faster than Canvas? JPEG.

Of course these tools have different use cases. Handling scaling events and interactivity with Canvas is far, far more laborious.

The great thing about SVG (and to a lesser extent JPEGs) is that you can produce them anywhere, not just in a browser with a JavaScript VM.

Re: Easy SVG sparklines

#25
post #10

But SVG is slower than Canvas. The main use case for sparklines is embedding them into cells, many hundreds or even thousands of them [1]. With hundreds of SVG files page becomes becomes visibly slower (first paint, scroll, interactions). I suggest to invest some time and check canvas solution too. [1]: https://www.google.com/search?q=sparkline&tbm=isch

Hard to imagine that pure-HTML SVG is really slower than Canvas which relies on JS..

Ah, but Canvas does not rely on JS. You would update it using JS, yes. When you don’t update it, it’s just another image. Browsers are quite good at images.

In the end, I think it’s down to the complexity of the graph and the dimensions (in pixels, because images need memory, too).

Re: Easy SVG sparklines

#26
The "unfinished" tiny line graph with no fill is actually closer to what Tufte meant by sparklines. He meant those to be placed in text, word-sized, along with words to help communicate better.

https://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=...

I feel like many people use "sparkline" to mean "pretty graph." Those, frankly, lack the punch of a sparkline.

Re: Easy SVG sparklines

#27
post #10

But SVG is slower than Canvas. The main use case for sparklines is embedding them into cells, many hundreds or even thousands of them [1]. With hundreds of SVG files page becomes becomes visibly slower (first paint, scroll, interactions). I suggest to invest some time and check canvas solution too. [1]: https://www.google.com/search?q=sparkline&tbm=isch

> The main use case for sparklines is embedding them into cells

Says who? Citation?

Re: Easy SVG sparklines

#28
post #10

But SVG is slower than Canvas. The main use case for sparklines is embedding them into cells, many hundreds or even thousands of them [1]. With hundreds of SVG files page becomes becomes visibly slower (first paint, scroll, interactions). I suggest to invest some time and check canvas solution too. [1]: https://www.google.com/search?q=sparkline&tbm=isch

This is only an issue on chrome-based browsers; performance in Firefox is much closer to what you would expect. You can/could (late 2022) reliably crash chrome by displaying 1000+ unique SVG files on one page, with each SVG simply displaying a single line of text. My current workaround is rendering the SVGs to png serverside if the client is chrome-based, as canvas feels like the wrong solution.

Re: Easy SVG sparklines

#30
I've used a similar technique to implement one of the graphs for small "header dashboard" for a trading tool at my previous job. It was replacing an old decrepit tool and I wanted to add some pizzaz to the tool, and had an obsession with SVG and micro interactions at the time, so I've basically implemented most of the little graphics using hand-emitted SVG that was manipulatied through React. The updates happened in one batch too, so the performance was always great
Post reply on HN