-
Notifications
You must be signed in to change notification settings - Fork 310
Description
In working with discrete-time and discrete-level data, I find that the risers in the data can end up being visually deceptive, especially where there is a single-level change involved. Use of a collection of "dots" appears to be much slower to render than the path used by d3.line, to the point of making scrolling and zooming even on a desktop browser rough, and nearly impossible on a phone.
From a presentation standpoint, the dot is "fine" -- it is just the performance problems, especially as mobile monitoring of the time series is a primary use case.
At least for me, the visual impression of how many samples are at the median vs. high/low over a segment of time is very different between the two representations.
(Using d3.line has similar challenges with the near-vertical connectors as d3.curveStep has with the risers.)
On a desktop, the dataset-size limit is around 1000-1500 dots before the re-draw times introduce so much lag as to make scroll/zoom frustrating. (There are three other d3.line data sets as well on the graph, but it is the dots that dramatically slow the re-draw time)

