Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Easy SVG sparklines

alexplescan.com

Post reply on HN
Print view View original

61–70 of 106 posts

Re: Easy SVG sparklines

#61

Post by klysm »

llm_nerd wrote: post #35
klysm wrote: post #23

Earlier quoted context omitted.

SVG could never be as fast as canvas.

SVG is a series of drawing commands (with transformations, filters, and so on). Which is exactly what canvas is. With appropriate layer caching of course it can be 100% as fast if the rudiments are similar and in the same context[1], and on many platforms it is. Chromium derivatives have a particularly slow implementation of SVG and it has tainted the whole realm. [1] Obviously if you're zooming and transforming and…

Canvas is just a pixel buffer. Even with sufficient caching SVG would be slower because there’s more work to do with parsing, etc.

Re: Easy SVG sparklines

#62

Post by jjcm »

I ended up hand crafting my svg graphs for non.io for many of the same reasons. I originally was looking around at 3rd party libraries, but one of my goals with the site was to use as few external libraries as possible. I made an attempt at dynamically generating the svg points myself, and found it incredibly easy.

For context, here's the 22 lines of code it took to create a simple svg graph: https://github.com/jjcm/soci-frontend/blob/master/components...

And here's the final output: https://non.io/Animation-example

Re: Easy SVG sparklines

#64

Post by tripflag »

dylan604 wrote: post #39
tripflag wrote: post #28

Earlier quoted context omitted.

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.

Since the vast majority of users are a chromium based browser, doesn't this put the burden on your server pretty much all of the time? why even bother with code to do 2 different things when the other thing is such a niche segment of users?

True; so the server-side rendering is tuned for minimal server load, with the resulting output being heavily degraded. Still good enough for its purpose, and Firefox gets the bonus hi-res thumbnails :-)

Re: Easy SVG sparklines

#65

Post by wbobeirne »

chefandy wrote: post #38

Maybe it's just because I have so much experience with design and visual art, but I think SVG is one of the most, if not the most underutilized web format. It's great for the self-contained static vector graphics that it's most commonly used for, but it can do so much more. SMIL animations can be a little clunky, but having an alternative to gif and video that doesn't require JS is pretty rad-- especially for throbbe…

Totally agree. I bookmarked this guide that hit the top of HN a few weeks back, a good primer on how to get started manually programming paths, which unlocks a lot of cool dynamic SVG and animation opportunities: https://www.nan.fyi/svg-paths.

Re: Easy SVG sparklines

#66

Post by jancsika »

XCSme wrote: post #48
xyzzy_plugh wrote: post #24

Earlier quoted context omitted.

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 JavaScrip…

> You know what's even faster than Canvas? JPEG Is that true? Isn't canvas a bitmap whereas JPEG requires decoding?

What's the fastest way to deliver the bitmap to the canvas?

Re: Easy SVG sparklines

#67

Post by stevekrouse »

dreadlordbone wrote: post #44
entropie wrote: post #43

Earlier quoted context omitted.

It would be nice if you consider to put it in a jsfiddle, or something.

Good point, updated that to a jsfiddle.

I ported your jsfiddle to run on val town!

Main function: https://www.val.town/v/stevekrouse.sparklineSVG

Rendered example: https://www.val.town/v/stevekrouse.sparklineEx2

Re: Easy SVG sparklines

#68

Post by stevekrouse »

I thought it'd be fun to play with sparklines on Val Town, which is a server-side platform for running JavaScript.

First I did the opposite of this post and used all the libraries (react, htm, and react-sparkline): https://www.val.town/v/stevekrouse.sparklineEx

Then I found a comment below that does it in vanilla js, so I ported that over to Val Town as well: https://www.val.town/v/stevekrouse.sparklineEx2

Re: Easy SVG sparklines

#69

Post by leeoniya »

082349872349872 wrote: post #5
leeoniya wrote: post #2

this works well when you have a few sparklines with a dozen datapoints each, but less well when you have many sparklines with hundreds of datapoints.

I'd bet an SVG can easily handle hundreds, if not thousands, of datapoints.

it can for sure "handle" it. the question is "how well"?

a sparkline with 100 datapoints is very realistic. and having a couple columns in a table with 100 rows filled with these svg sparklines will have ui lag that you'll definitely feel.

sadly, svg is not a great performer in these 1k+ datapoints cases and you gotta switch to canvas.

Re: Easy SVG sparklines

#70

Post by llm_nerd »

klysm wrote: post #61
llm_nerd wrote: post #35

Earlier quoted context omitted.

SVG is a series of drawing commands (with transformations, filters, and so on). Which is exactly what canvas is. With appropriate layer caching of course it can be 100% as fast if the rudiments are similar and in the same context[1], and on many platforms it is. Chromium derivatives have a particularly slow implementation of SVG and it has tainted the whole realm. [1] Obviously if you're zooming and transforming and…

Canvas is just a pixel buffer. Even with sufficient caching SVG would be slower because there’s more work to do with parsing, etc.

Canvas is a pixel buffer...and a set of drawing rudiments to imperatively actually make that pixel buffer useful. If you were actually just using canvas as a pixel buffer it would be catastrophically slow.

SVG is a pixel buffer and a set of drawing rudiments to imperatively or declaratively actually make that pixel buffer useful.

The distinction you are drawing between these is sophistry.

Post reply on HN