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.
Totally. I just mean that logic has to live somewhere, whether in client-side JS or a server. It's not a great practice to just blindly render SVGs out of raw data.
Aha, I misunderstood — I'd thought you were thinking of rendering multiple small SVGs.
Good point, although decimation for sparklines shouldn't be that difficult: I've done completely stupid decimation (recursively split stopping whenever linear fit is close enough) for live GPS traces and (because people are only using them qualitatively) no one ever complained.
Comments
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.
+1, the whole point of a sparkline is to compactly show a trend. Packing a gazillion data points is not the right use
Totally. I just mean that logic has to live somewhere, whether in client-side JS or a server. It's not a great practice to just blindly render SVGs out of raw data.
Aha, I misunderstood — I'd thought you were thinking of rendering multiple small SVGs.
Good point, although decimation for sparklines shouldn't be that difficult: I've done completely stupid decimation (recursively split stopping whenever linear fit is close enough) for live GPS traces and (because people are only using them qualitatively) no one ever complained.