leeoniya / uplot Goto Github PK

there might be way too many possibilities here. it may make sense to just add the ability to add some extra space to any side of the chart and allow the legend and/or title to be positioned using css.

Thanks for this great library!

Is it possible to support dynamic updates like the following?
http://dygraphs.com/tests/dynamic-update.html

• data format & requirements
• how scales, axes and series interact
• DOM structure: classes of axes, labels, cursors, points, plot, grid, chart
• mouse interaction: zoom/unzoom, focus-hover (plot & legend), cursor lock/unlock, legend series toggle
• series.value can be a template string if time: true
• passing then to constructor to fire init after custom dom injection

declarative opts:

• .data
• .hooks
  • init
  • setScale
  • setCursor
  • setSelect
  • setSeries
  • setData
  • setSize
  • drawClear
  • drawAxes
  • drawSeries
  • draw
  • ready
  • destroy
• .plugins
• .title
• .id, .class
• .width, .height
• .gutters: {x, y}
• .scales
  • .auto
  • .time
  • .range (fn and array)
  • .from
  • .distr
  • .min, .max
• .axes
  • .show
  • .side
  • .stroke
  • .scale
  • .incrs
  • .split
  • .values (fn and stampsCfg array)
  • .space (fn and number)
  • .size
  • .gap
  • .font
  • .label
  • .labelSize
  • .labelFont
  • .grid
    • .show
    • .stroke
    • .width
    • .dash
  • .ticks
    • .show
    • .stroke
    • .width
    • .dash
    • .size
• .series
  • .show
  • .paths
  • .scale
  • .label
  • .stroke
  • .fill
  • .alpha
  • .width
  • .dash
  • .value
  • .values
  • .band
  • .spanGaps
  • .class
  • .points
    • .show (fn or bool)
    • .size
    • .width
    • .stroke
    • .fill
• .cursor
  • .show
  • .points
    • .show (fn or bool)
  • .x, .y
  • .drag: {setSelect, setScale, x, y}
  • .sync: {key, setSeries}
  • .focus: {prox}
  • .lock
• .focus: {alpha}
• .select
  • .show
• .legend
  • .show

instance properties and methods:

• .root
• .width, .height
• .ctx
• .bbox
• .redraw()
• .scales, .axes, .series, .cursor, .hooks, .data, .ctx, .select (state inference)
• .batch()
• .setData(), .setScale(), .setCursor(), .setSeries(), .setSelect(), .setSize()
• .destroy()
• .tzDate
• .posToIdx(left)
• .posToVal(left/top, scaleKey)
• .valToPos(val, scaleKey)

static properties and functions:

• uPlot.fmtDate
• uPlot.tzDate
• uPlot.rangeNum
• uPlot.assign

or, more accurately, de-focus all but the closest.

the cursor.focus branch is a mostly-complete implementation of this dygraphs' highlighted-series demo [1].

i'm not entirely convinced that this is something valuable enough to keep (at least in this format). i'd like to see a real use-case when seeing an isolated trend is indispensable in the presence of dozens or hundreds of series. most of the interesting info in these will just be visual outlier detection, which does not actually require a canvas redraw, but simply quick identification of the hovered series/data point and its value.

i want to stay away from "cool" features that add code and impact perf but don't add much value in terms of data inference.

[1] http://dygraphs.com/gallery/#g/highlighted-series

The benchmarks seem rather variable since they're based on only a single run currently. I think the numbers would be more reliable if it created a new chart in a loop 50 or 100 times and then took the average

Is there a option to have a series toggled off initially?

http://dygraphs.com/gallery/#g/highlighted-weekends
http://dygraphs.com/gallery/#g/highlighted-region

also annotations along the axes/scales (vt or hz lines that mark some specific event in time or some level along a y axis).

series annotations [1] will probably be handled by #10:

[1] http://dygraphs.com/gallery/#g/annotations

Adding an issue to track based off the discussion at chartjs/Chart.js#6695 (comment)

Most financial applications such as Yahoo Finance, Trading View, etc. have each data point equally spaced apart. I originally didn't notice this wasn't done on the gold high/low example because there were lots of points. But it's more noticeable when there are fewer points or the points are drawn as candlesticks, ohlc, or bars because you end up with gaps for weekends.

The actual logic is really simple. Each point is just placed on the x-axis by index / numIndices. (The Chart.js code for this is stupidly over complicated and a terrible example to follow so I wouldn't even look at it as it would only confuse)

example: https://bl.ocks.org/1wheel/0e7f71ac0325b9be92c9dd19fe4bcc44

first step is to re-use the dom of existing labels rather than destroying and re-creating them on each .setView() and .setData(). this might be good enough.

maybe draw axis labels on canvas rather than the DOM. they will always change together with series lines and grid, which already get drawn on canvas. this will also make it easy to export the graph as an image.

there are trade-offs to this.

there are 2 main features lost by moving away from the dom:

• css styling flexibility, & auto-text wrapping (will have to implement this in js [1]
• accessibility (crisp text resizing on pinch zoom)

i dont want to bloat the options with every possible styling option to compensate for loss of CSS. instead, we should provide some basics (font size, color, weight) plus access to the raw ctx so anything else can be set directly [2] by the supplied axis.values function.

[1] https://stackoverflow.com/questions/2936112/text-wrap-in-a-canvas-element
[2] https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Drawing_text

You can use the Intl API to format times so that they render in other language-agnostic format. E.g. I work on a site that supports both English and Spanish and "October" would automatically show up as "Octubre" in my charts on that site because they're using Luxon which uses the browser's Intl api under the covers. You don't need to provide any translations as the browser has them built in. You could either use a library like Luxon or use the Intl API directly

currently width maps directly to ctx.lineWidth. this might be somewhat unexpected when taken with the fact that chart width and height are specified in logical (css) pixels and the canvas itself may be larger (multiplied by devicePixelRatio). all internal canvas ops are also specified in canvas pixels.

this might be ok, and certainly provides a lot of fine detail, but does not result in a true 1px css width.

the question is whether the canvas ops and line widths should be adjusted to match the devicePixelRatio? i'm thinking yes for a default but should it be possible to toggle this behavior to take advantage of the full canvas resolution (as is done now).

eg ability to draw candlesticks at the datapoints.

https://news.ycombinator.com/item?id=21216316

I usually have timestamps (millis since epoch) from the server. But often I want to display in a different time zone. E.g. in Pacific Time or the user's local time for server monitoring. In NYC time zone for finance applications.

Luxon has a really clever way of supporting time zones via the Intl api, which is the best I've seen. I have an open PR to add this feature to the date-fns library as well, which the author sounded interested in, but wanted to wait for a future release. Potentially you could use one of these libraries or another option would be to copy some of the code needed for support

an option to pre-define fixed scales and disable auto-rescaling.

let opts = {
  scales: {
    "myScale": {
      min: -5,
      max: 100,
    },
    "yourScale": {
      min: 0,
      max: 1500,
    },
  },
};

Would it be easy (and still performant) to be able to choose for a scatterplot instead of linechart per series?

Series can be toggled in the UI, an API to control and queries the toggled series would be really useful.

I've tested it for streamed data and it works really nicely and fast. Thanks a lot for your library !!!

could be useful for sparklines.

probably axis.show & legend.show

eg ability to draw candlesticks at the datapoints.

https://news.ycombinator.com/item?id=21216316

Architecturally, some additional chart types can be supported as long as they conform to the following:

• X values must be numbers, increasing and unique
• Y values must be numbers, null or undefined for data gaps
• X and Y arrays must be equal length

const data = [
  [1566453600, 1566457260, 1566460860, 1566464460],   // x values
  [0.54,       0.15,       3.27,       7.51      ],   // series 1
  [12.85,      null,      13.65,      14.01      ],   // series 2
  [0.52,       1.25,       0.75,       null      ],   // series 3
];

this means we can support:

• line (numeric & time)
• line with custom markers (box plots, candlesticks, stock (OHLC)
• vt bar (column)
• hz bar

while the x-values have to be numeric, x labels can be text, so for something like this:

you could simply keep a map in app-space

let xCats = ["Censys", "Gharchive", "NYTimes"];

let data = [
  [   0,     1,     2],
  [3.09,   2.7,  2.92],
  [1.93,   1.6,  2.02],
  [1.06,  0.93,  1.22],
];

let opts = {
  scales: {
    x: {
      type: 'n'
    }
  },
  series: {
    y: [
      {label: "PyPyBaseline"},
      {label: "PyPyKeySringCaching"},
      {label: "PyPyMapNoCache"},
    ],
  },
  axes: {
    x: {
      values: (vals, space) => vals.map(v => xCats[v]),
    }
  }
}

Usecase: finance time-series of N symbols of which to check their correlation. These have different y-scale, but always the same x-scale.

Plotting them in same plot due to variance in y-scale doesn't work most of the time.
Therefore, I want to have a couple of plots side by side.

It would be awesome to be able to sync between plots:

• x-scale. Zoom in on 1 plot, zooms in on others. Note that the user has to make sure that the same data in terms of time is given for each plot to begin with.
• crosshair. Hover over 1 plot, will show crosshair dotted x + y-lines (including highlighted numbers) on all plots.

Thoughts?

For axes y: space works as expected, but min and max looks not working.
For axes x: the display is always time type, even I use type: "n".

axes: {
          x: [
               {
                 type: "n",
                 scale: 'x',
                  //values: (vals, space) => vals.map(v => v*100),
                  min: 0,
                  max: 10,
                  space: 50,
                }
            ],
            y: [
                {    type: "n",  //"t" is for time; "n" for number
                     scale: 'y',
                     //values: (vals, space) => vals.map(v => v*1),
                     min: -20,
                     max: 20,
                     space: 50,
                }
            ],
}

...instead of chart level and clamp the min/max ranges.

so that zoom-drags which end off-chart are properly handled.

https://news.ycombinator.com/item?id=21212058

if a label ends up on the far right edge of the chart as it does here [1], it will always protrude outside the chart edge. this doesn't happen on the left because a y axis is typically there and provides a buffer.

probably makes sense to just stick a faux/empty secondary y axis on the right side as well to pad it out and keep the code uniform.

[1] https://leeoniya.github.io/uPlot/demos/months.html

hopefully without bloating too much code. might just resort to on-screen buttons hooked up to an API rather than dealing with implementing gesture / double-tap detection (lots of extra code, probably fragile)

https://news.ycombinator.com/item?id=21210843

this logic [1] can use a bit of tweaking. specifically, something like this should be better at high granularity:

instead of:

12am    1am    2am    3am
Oct 1  Oct 1  Oct 1  Oct 1

this:

12am    1am  2am  3am
Oct 1

same for hours, months, etc.

[1]

i'll tag people here whose issues & use-cases in other charting libs could be good opportunities to try uPlot.

I'm attempting to plot a live-updating data set however instead of the new data getting drawn, uPlot will always draw the original paths. After some digging I realized that my xAxis never changes, causing the series' paths to never be reset.

A simple example of the data I'm plotting (notice the x axis data doesn't change)

setData([[1, 2, 3, 4, 5], 
         [1, 3, 5, 7, 9]])
...
setData([[1, 2, 3, 4, 5], 
         [2, 4, 6, 8, 10]])

This appears to be the relevant code:

Right now I'm working around the issue with uplot.series.y.forEach(s => (s.path = null)) right before my call to setData but that seems less than ideal. Is there a more obvious way I should be doing things? Or is this an issue with the library itself? Thanks in either case.

https://leeoniya.github.io/uPlot/bench/uPlot.html

It gets stuck on Rendering... with this error in the console:

Uncaught TypeError: Cannot read property 'show' of null
  at uPlot.iife.min.js:2
  at Array.forEach (<anonymous>)
  at uPlot.iife.min.js:2
  at rt (uPlot.iife.min.js:2)
  at ut (uPlot.iife.min.js:2)
  at A (uPlot.iife.min.js:2)
  at new n.Line (uPlot.iife.min.js:2)
  at makeChart (uPlot.html:121)
  at uPlot.html:134

Maybe related to 3633f6a

ZingChart utilizes canvas, so would be interesting to add to the benchmark.

Also, I noticed Highcharts was listed. I think it'd be interesting benchmark it with the boost module as well.

What are the different options we can use for scale (%, mb are provided in the example). What are the rest?

this might be somewhat involved, since grid & axes ticks are equally spaced right now, and determination of granularity is based around this fact.

This isn't a issue. I just want say thanks. Hope more people use it.

To select the best line chart package for my project, especially when points are about 2 millions. uPlot becomes No.1. Even it is fast than direct lineTo for Canvas. It is amazing. Thanks for the great work.
Please see the detail at https://github.com/rubyzhao/LineChartPerformanceCompare

Changing the README.md example to have all y values as 0 causes an error.

const data = [
        [1566453600, 1566457260, 1566460860, 1566464460],   // Unix timestamps
        [0,       0,       0,       0 ],   // CPU
        [12.85,      13.21,      13.65,      14.01     ],   // RAM
        [0.52,       1.25,       0.75,       3.62      ],   // TCP Out
    ];

Console message

uPlot.iife.js:755 Uncaught TypeError: Cannot read property '0' of undefined
    at uPlot.iife.js:755
    at Array.forEach (<anonymous>)
    at drawAxesGrid (uPlot.iife.js:738)
    at setView (uPlot.iife.js:823)
    at setData (uPlot.iife.js:440)
    at new uPlot (uPlot.iife.js:1036)
    at (index):46

lines 754 to 756

				var ref = findIncr(max - min, axis.incrs, opts[dim], axis.space);
				var incr = ref[0];
				var space = ref[1];

My data has large sections of zeros and I believe I have reproduced the problem with the example data.

all y-scales have a buffer added above and below their min/max values since we don't want a chart where the min/max are all the way to the top/bottom edges of the plot. if the value is a never-changing 100, then you get a reasonable 50-150 range since we don't know if the value can go above or below. using the same logic for never-changing 0 we end up with a range of -0.5-0.5, which places 0 off the bottom of the plot and you end up with an unavoidable bottom gap even if there's never data that ever actually goes negative.

this is probably a common-enough case where we can clamp the scale's min at 0.

non-changing 100 looks reasonable:

non-changing 0 shows a buffer area that extends to -0.5:

Show a chart of the performance comparison in the readme. The readme has a table of values that would be easier to compare and see the differences in a chart. I hear uPlot might be good for that sort of thing. 😄

db2b05b#r35853039

right now when a series is toggled, the scale associated with it is invalidated (along with all paths using that scale) and recomputed and paths redrawn.

by additionally keeping track of which series bumped the final scale min/max, we can avoid invalidating the scale when toggling a series that never affected the its associated scale. this would avoid recomputing the min/max of the scale and regenerating the other paths, which would provide a healthy improvement by avoiding most of the work. this is especially apparent when you have a lot of data-heavy series on the same scale.

what's involved is adding a prop or two to the scale itself for tagging which series indices pegged the min/max values by keeping track inside of setScales(), then adding a check in toggle() to avoid unnecessary invalidation.

Can we export chart as jpeg/png?

https://mobtowers.com/2013/04/15/html5-canvas-crisp-lines-every-time/

it seems inevitable that there will always be a trade-off between positional accuracy and having crisp lines at data densities exceeding the available pixels.

right now all coords are shifted in the + direction by half the stroke width. this has the effect of aligning the left side of the line at the correct offset and providing crisp results at whole-numbered stroke widths. however, it causes some issues at the far edge of the canvas.

these diffs are minor (single or sub-px range), but it would br good to spell out & reason about the chosen behavior more precisely.

Use case: Our sensor dashboards are shared by a team of 7 scientists. Some of them have their screens rotated (portrait). They both want to maximize screen usage without changing the code.

Would it be possible to add a "stretch to fit" option?

the current design relies on two datapoints in the data to act as x-min/max values for the viewport.

an issue with this is that with sparse datasets it becomes impossible to zoom in enough on a single point to get high grid and label resolution.

an example would be some event that occurs on the 1st of each month any time between 12am and 1am.

right now it's possible to see the exact timestamp in the legend by hovering near the datapoint, but impossible to get visual sub-hour resolution in the chart because the min range between 2 datapoints will be ~30 days * 24h. at 40px min label spacing, your screen would need to be 28,800 pixels wide to see hourly labels, half that to see bi-hourly, etc.

this change will likely not be trivial.

Quickly looking at the code, it looks like only time series are supported currently — X axis can only be timestamps (not sure though since there are no docs yet). Would it be possible to support non-timed use cases (with custom-formatted X axis)?

Hi!

uPlot seems to be perfect for my needs since I don’t need most of the knobs and whistles offered by other libraries. Thanks for making this!

Would it be possible to see it published as an NPM package?

...independently of any series.

yay? nay?

to avoid unintentional right click or wheel interactions

https://news.ycombinator.com/item?id=21211346

http://dygraphs.com/gallery/#g/temperature-sf-ny

dygraphs calls them "error bars" but a uPlot impl would be generic min/max. this will require area fill code to be added.

dunno if the bands should be their own series or be defined as part of an existing one.

the data format would probably be

const data = [
  [0,1,2,3,4],  // x vals
  [
    [7,3,5,7,9],  // main values (can be median, mean, geo mean, etc)
    [7,3,5,7,9],  // min vals
    [7,3,5,7,9],  // max vals
  ]
];

Is it possible to plot a high / low band and a separate line?

I wrote a feature for Chart.js that I've been calling "major ticks". I think it's best demonstrated with this example: https://www.chartjs.org/samples/latest/scales/time/financial.html

As you can see, it makes sure that the first hour, day, month, etc. is chosen for use as a label and formatted differently.

Is this a feature you'd be interested in adding to uPlot? If so, I'd be happy to help describe how it works in more detail. It's slightly slower than just naive label display since it needs to do some extra calculation, but not by much. In Chart.js it's an option so you can turn it on and off, and I'm sure we could do the same here.

See http://dg.cx/uplot-nochange-timeseries.html (should see two graphs, only one works). But essentially findIncr returns nothing if the value in a series never changes.

[Thanks for writing this, looks ideal for writing a fast Prometheus frontend...]