Oh OK. Thanks for explaining.
If it was a graph it would be at best uninformative, at worst misleading.
But it's not a graph, it's a sparkline so all is well.
Oh OK. Thanks for explaining.
If it was a graph it would be at best uninformative, at worst misleading.
But it's not a graph, it's a sparkline so all is well.
Perhaps consider a svg instead, highly performant, other complexity probably.
D3 does use SVG for drawing. And the graphical part is not the bottleneck.
Main problem is the data. If to support live data just as chart node, then as the graph is pretty tiny, it will be unreadable crap very fast. So long periods will be not possible.
Live data can be downsampled on fly. And it is not expensive process. For example collecting environment temperature readings with rate 4 samples in minute can be downsampled so that 7 days make about 1500 data points. But that method doesn't necessarily apply for every possible measurable process.
So pretty weak argument to build something on top of it.
If to deal with historical data. There's no way to apply any down sampling logic. It will kill the browser. Or at least stall for many seconds. It is not frontend job.
Limiting the data points to some low value makes the widget pretty pointless. Same goes if to limit the timespan.
The problem definitely is not that simple as I described if to go deeper in details.
I think I would add a simple data check to limit the data elements and output a warning/error when exceeding a reasonable amount based on a sensible maximum number of horizontal pixels in a typical sparkline.
I've done testing on dynamic builds of HTML data tables and nested lists which are likely to be a lot more complex. Desktop browsers had no real issues handling 10k entries (tables, 24k for nested lists) other than having a several second delay while the UI gets built. Of course, mobile browsers might be rather more limited.
The responsiveness of the D2 layout affects on x axis (horizontally if you prefer). Widget dimensions cant be fixed. Specially if dashboard will be built for multiple screens, the actual size cant be more than a lucky guess.
OK moving forward a bit.
As i mentioned, live data can be downsampled. I have method sort of figured out but I can't be sure how it works for different sensor / environments / situations / ...
I need a bit help here. Contribution is easy, you'll just need to run a test (or couple) for me.
Test is easy, I give a flow, you configure it a bit and run for configured time. Then you do a screenshot of the result, send it back to me and that's basically it.
Requirements:
You must be interested.
You should not run any tests on live/production environment.
You must have some kind of sensor for live data.
Fake/computed/manual data inputs are not subject of interest
Temperature sensor's are fine but I'd hope to get something what I don't have.
You have Dashboard 2 installed.
Test should run at least 1 hour but longer is better.
As to not get very confusing pingpong of mixed results, the communication goes personally via private/direct messaging.
SO
To get your name into the contributors list,
(and overall to turn this idea to widget)
(and the requirements fit for you)
send me a note
PS: I have busy weekend this time but that is just this weekend so if I cant reply right away just wait a bit..