11–20 of 106 posts
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
Earlier quoted context omitted.
Then you have to deal with scaling, responsiveness, data decimation, etc. It's not really a good idea to just have a multi thousand point line chat rendered real tiny
If you know what size you're dealing with it's not a huge deal. You can quantize the data and for (small) sparklines that's probably fine because most people view them as miniature glimpses at data rather than granular and accurate.
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.
Why do you think this is going to be a problem?
For those who don't know, there's a font called Sparks that uses glyphs to create sparklines: https://github.com/aftertheflood/sparks
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
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..
Simple, data-driven graphics like this is one area where SVG really shines, I think. No need to load a JavaScript charting library if you just want some simple line charts like this. I create SVG images fairly often, and maybe half the time I find myself hand-coding them, or at least hand-tweaking them, since I enjoy the magic of seeing code turn into something visual.
Simple, data-driven graphics like this is one area where SVG really shines, I think. No need to load a JavaScript charting library if you just want some simple line charts like this. I create SVG images fairly often, and maybe half the time I find myself hand-coding them, or at least hand-tweaking them, since I enjoy the magic of seeing code turn into something visual.
Earlier quoted context omitted.
Then you have to deal with scaling, responsiveness, data decimation, etc. It's not really a good idea to just have a multi thousand point line chat rendered real tiny
If you know what size you're dealing with it's not a huge deal. You can quantize the data and for (small) sparklines that's probably fine because most people view them as miniature glimpses at data rather than granular and accurate.
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..
I don't even mention the fact that article suggests to return each SVG sparkline in a separate request.