LightningChart JS Logo

Announcing LightningChart JS v9.1.0 

In this release

The Data Capacity Update

LightningChart JS version 9.1.0 is available today. Where v9.0.0 rebuilt how data moves through the library, v9.1.0 removes the ceiling on how much data an application can hold in total, across however many charts it contains. By enabling WebAssembly.Memory, a LightningChart JS application can now use as much RAM as the machine has available. For example, we created a multi-channel XY line chart holding 29 billion data points.

In this release

PERFORMANCE NEW FEATURE

1. WebAssembly.Memory Utilization

LightningChart JS can now allocate far more memory than a standard browser page allows, by making use of WebAssembly.Memory. This is a built-in, well supported browser capability, and in LightningChart JS it is enabled by passing a single flag.

const dataSet = new DataSet({
  useWasmMemory64: true,
  schema: {
    // ...
  }
})

The practical effect is that the amount of data you can load is no longer governed by a hard browser limit. It is governed by the physical RAM in the machine running the application. Actual behaviour and performance vary between browsers, but across our testing the pattern held: the more RAM the hardware has, the more data LightningChart JS can hold.

The 29 billion data point measurement above was taken with 110 GB of RAM allocated, storing the data as 32-bit floats.

Why this matters: until now, loading a very large historical data set into a browser chart meant decimating it first, paging it in from the server, or rebuilding the application on a native desktop stack. Raising the memory ceiling removes that compromise for a large class of engineering, scientific and industrial applications where the full-resolution record is the thing the user actually needs to see.

It also matters for how these applications get built. Desktop software handling data at this scale has traditionally meant native, platform-specific development. With the memory ceiling lifted, the same work can be done with web and cross-platform technologies, without giving up the data sizes the job requires.

PERFORMANCE

2. New Data Capacity Benchmarks: First Results

We are re-running our full performance comparison against other data visualization solutions to reflect this change. That work is still in progress and will be published separately. Two results are already confirmed and worth sharing now.

Measure Before v9.1.0 With v9.1.0
Average data set size handled, compared against other data visualization solutions 87,740 times larger 337,050 times larger
Maximum confirmed data set visualized as an interactive line chart 4 billion data points 29 billion data points

The remaining measurements, along with the full methodology and source code, will follow in an update to the JavaScript charts performance comparison repository on GitHub, so every figure can be reproduced rather than taken on trust.

DEMO

3. A 28 GB Interactive Dashboard, Running in Public

To show what the new memory model makes possible outside a benchmark, we built a realistic motorsports telemetry application as an Electron desktop app. It loads 28 GB of data into a single interactive dashboard and stays interactive while doing it.

The project is published in full, so the memory configuration, the data loading strategy and the chart setup can all be read and reused. See the lcjs-wasm-memory64-demo repository on GitHub.

NEW FEATURE BEHAVIOUR CHANGE

4. Automatic Data Sorting Within Batch

From v9.1.0 onward, LightningChart JS automatically sorts incoming data when the data schema is declared as progressive.

This is primarily a win for new application development. Over the years a recurring source of hard-to-diagnose rendering problems has been data arriving out of order without the developer knowing it, usually because of an upstream queue, a multi-source merge or a network reordering. Sorting the batch on input removes that whole category of bug.

Existing applications should check this setting. If your data is already guaranteed to be in order, automatic sorting is work your application does not need, and leaving it on will noticeably slow chart performance compared with v9.0.

Applications where this applies will print instructions to the browser console on first run after the upgrade, and the same guidance is in the performance optimization guide.

Automatic sorting can be disabled on the DataSet:

const dataSet = new DataSet({
  autoSortingEnabled: false,
  schema: {
    // ...
  }
})

Or on an individual series:

const series = chart.addLineSeries({
  autoSortingEnabled: false,
})

NEW FEATURE

5. Per-Data-Point Colouring for 3D Line Series

LineSeries3D and PointLineSeries3D now support IndividualPointFill, so every data point in a 3D line series can be coloured separately and programmatically.

This brings 3D line series into line with what was already possible in 2D, and it matters most when the colour is carrying a third or fourth variable: signal amplitude along a flight path, temperature along a pipe run, or classification state along a trajectory.

NEW API

6. Heatmap solveNearest From an Axis Coordinate

Heatmap series gain a new solveNearest syntax that resolves the nearest original data point to an arbitrary axis location given as X and Y.

Previously this kind of lookup started from a screen position. Starting from an axis coordinate instead makes it straightforward to drive a heatmap readout from something other than the mouse: a shared cursor across several charts, a value typed into a field, or a position streamed in from another part of the application.

NEW FEATURE

7. 3D Series Interaction Events Report Original Data Samples

User interaction events on 3D series, including pointermove, pointerenter, click and dblclick, now report full original data sample information, in the same way XY series have done for some time.

The immediate benefit is synchronised interaction between 2D and 3D views of the same data. Hovering a point in a 3D scatter can now highlight the exact same sample in an XY time series beside it, without the application having to reverse-engineer which sample was hit.

IMPROVEMENT

8. Improved Gauge Chart Value-Settling Animations

Gauge chart animations have been reworked so that the needle settles on a new value more smoothly. The difference is most visible on gauges driven by live data, where frequent small updates previously produced a busier movement than the underlying signal warranted.

9. Updating

# npm
npm install @lightningchart/[email protected]
# yarn
yarn add @lightningchart/[email protected]

v9.1.0 is a backwards compatible release. If you are on v9.0.x this is a drop-in upgrade, with the one behaviour change covered in section 4 above. If you are upgrading from v8, the v9.0.0 migration guide still applies.

The complete list of changes for this version will be published in the version history.

Get started with LightningChart JS v9.1.0