Expanding more on the logic of loading everything in around the user's currently zoomed/panned window, how much data would be considered appropriate to keep stored as the user is panning along the time axis?
With things like pturmel's pageVarMap we can technically store more data that is actually being provided to the chart. But then that gets into the problem of if the user is jumping around the time span, you end up with holes in the data, and need to reprocess it to fill in the missing holes.
How big of a window would you expect as a user to be able to view?
@nminchin How much data does the software you were showing in the post below retain?
Is it just storing data since the user opens the trend? Does it reach a point where it starts dumping data off the end?
When not displaying the trend, the UI queries only when told to, and holds just that data. When displaying the trend, it also queries when the time span is changed, and holds just the data in that new time span. The held data is not discarded until after the new query completes, to minimize chart dead time.
(If selecting tags in the tag list, only those tags are queried for the given time span.)
What would you consider a 'reasonable' data point density for various windows of time? (ie 1 hour, 1 day, 1 week).
For 1 hour, 5 second intervals or tighter seems reasonable but anything beyond a few hours and that becomes very heavy very fast with multiple tags.
Running a higher density in a span gives you the benefit of not needing to re-query every time you zoom in, but also adds overhead/increases load time as you have to deal with all that extra data.
I find it reasonable to expect somewhere between 1,000 data points and 10,000 data points on any given chart.
It all depends on the underlying data source and what information you’re trying to convey 
But yeah, from a performance standpoint, points per chart is more meaningful than points per time.
Put something together based on what we are doing internally and the examples of better trend viewers from various posts
It has basic pan and zoom functionality, I haven't taken a stab at the axis dragging to adjust bounds yet.
Looking good!
The axis divisions even make sense! 
I was a bit sad that I didn't see progressions like 17:27:12...17:31:56...17:36:12 though 
Maybe you can add a "disgruntled employee" option?
Impressive, the tooltips look great.
runs sudo rm -rf /* at a randomly chosen time.
I think those have my largest inline defined function yet (~200 lines), and it will probably get larger as I add more handling.
Lightly related, what color do you normally use for the x-trace line? I'm noticing that gray gets lost easily with multiple pens.
In this example from another SCADA I saw while googling, it's hot pink 
You can definitely see it... Or maybe this is an annotation marker?
I think it's black in Citect's ProcessAnalyst, and it does get a bit lost at times
I agree, it'd be nice to have the units in them as well to give context. Despite having the pens on engunits axes, it can still get confusing and means you have to look away to check the axis label. It becomes even more confusing if you have all the axes on the same plot
I'll add that to my list. It's going to be interesting because I don't think I have the units actually specified anywhere other than the scales.
I already touch those while building the tooltips so not hard to grab the units if they exist there. But then you get into issues with multiple eng units on one scale.
The other option would be to include the units in the definition of the dataset for the tag. (I'd probably go with this)
I'm already looking at making a tag browser/selector to go with this chart so I could probably have that grab the tag's units and stuff it in the dataset definition.
You think I should right align the numeric values while I'm at it? If I'm grabbing units I can grab/define formats as well.
I think so.
Couple of other things while you're reading in the engunits 
Can you read in the displ... you beat me to it
Edit: I forgot the 2nd of the couple. Is it hard to centre the date to the gridline? I think it looks a bit funny to the left 
Ah, that's being done because if you have it centered, it chops off chunks of the chart of varying size off the right of the last tick. Its a weird chartjs thing.
Note the white space to the right of the last tick that isn't present in the screenshot in my earlier post.
My issue is that the amount of space varies depending on how close the tick is to the right side of the chart. So while you are panning you are getting a lot of axis thrash, at least with display. It doesn't affect the panning movement itself.
Ah ok, that's not ideal. LeftRight-aligned (and left-positioned) it is!