Optimal strategy for real-time chart with 100k+ data points and smooth zoom/pan

[Syaptiyan]

Context

I am building a real-time monitoring dashboard that displays up to 100,000 data points. The chart needs to:

1. Update every 100ms with new data
2. Support smooth zoom and pan
3. Show tooltips on hover
4. Maintain 60fps performance

Current approach

I am using Chart.js with decimation plugin, but I am hitting performance issues:

const chart = new Chart(ctx, {
  type: "line",
  data: {
    datasets: [{
      data: realtimeData,
      pointRadius: 0,
      borderWidth: 1
    }]
  },
  options: {
    animation: false,
    parsing: false,
    plugins: {
      decimation: {
        enabled: true,
        algorithm: "lttb",
        samples: 1000
      }
    },
    scales: {
      x: {
        type: "realtime",
        realtime: {
          duration: 60000,
          refresh: 100
        }
      }
    }
  }
});

Problems

1. Zoom/pan is laggy when decimation is enabled
2. Tooltips are inaccurate because decimated points do not match original data
3. Memory usage grows unbounded over time
4. WebGL alternative (plotly.js-gl) does not support real-time updates well

Questions

1. What is the optimal decimation algorithm for real-time data?
2. Should I use Web Workers for data processing?
3. Is there a way to do GPU-accelerated rendering with Chart.js?
4. Should I switch to a different library (D3.js, ECharts, Highcharts)?
5. How to handle tooltip accuracy with decimated data?

Environment

• Chart.js 4.x
• chartjs-plugin-zoom
• chartjs-plugin-streaming
• React 18
• Chrome latest

Any insights on architecture patterns for this use case would be appreciated.

[PrinkleMahshwari]

Here is a comprehensive breakdown of the optimal architectural pattern to achieve 60fps real-time updates with 100k+ data points in Chart.js.

1. The Core Performance Issue: Streaming + Decimation

The reason zoom/pan is laggy is that chartjs-plugin-streaming and the built-in decimation plugin do not blend cleanly out-of-the-box at this scale. When parsing: false is active, Chart.js expects raw data arrays, but forcing the CPU to run the LTTB (Largest Triangle Three Buckets) algorithm over 100,000 points every 100ms kills the main thread.

2. Answers to Your Specific Questions

• Optimal Decimation Algorithm: For streaming data, MinMax decimation is significantly faster than LTTB. LTTB requires complex geometric area calculations per bucket, whereas MinMax simply finds the local peak and valley of a pixel-column bucket using primitive comparisons.
• Web Workers: Yes. You should absolutely move your raw realtimeData buffer array into a Web Worker. Let the Worker accept the incoming 100ms stream chunks, update the absolute data structure, handle data pruning (evicting data outside your sliding time window to stop memory growth), and pass only the downsampled 1000-point viewing window back to the main thread via structured cloning.
• GPU-Accelerated Rendering: Chart.js relies natively on the HTML5 Canvas 2D API, which has limited GPU acceleration. You cannot easily switch its rendering pipeline to WebGL.
• Tooltips Accuracy: If you downsample on the worker or via decimation, tooltips will only register for the remaining 1,000 downsampled points. To fix this, use a custom tooltip positioner/callbacks array that cross-references the closest time vector inside the worker's un-decimated raw array rather than reading chart.data.
• Alternative Libraries: If you want a drop-in 60fps WebGL/Canvas hybrid specifically designed for real-time 100k+ point monitoring, look into uPlot (ultra-fast, canvas-based) or Apache ECharts (excellent internal optimization and chunk loading).

---

🛠️ Optimized Architecture Code Example

Instead of relying on the streaming plugin to manage your huge array, manage a fixed-size dataset manually on a ticking frame layout and utilize MinMax pre-filtering.

// Complete performance tuning configurations for Chart.js
const chart = new Chart(ctx, {
  type: "line",
  data: {
    datasets: [{
      data: preDecimatedDataFromWorker, // Keep this strictly limited to ~1,000 to 2,000 points max
      pointRadius: 0,
      borderWidth: 1,
      elements: {
        line: {
          tension: 0, // Disable bezier curves entirely to bypass expensive mathematical interpolation
          cubicInterpolationMode: 'monotone'
        }
      }
    }]
  },
  options: {
    animation: false, // Essential: blocks layout animation recalculation loops
    parsing: false,
    normalized: true, // Crucial: tells Chart.js the data is already sorted chronologically by x-index
    spanGaps: false,
    responsive: true,
    maintainAspectRatio: false,
    scales: {
      x: {
        type: 'linear', // Switch to a fast linear numeric time-axis scale
        min: calculatedMinTime,
        max: calculatedMaxTime,
        ticks: {
          maxTicksLimit: 10 // Limit label calculations per tick cycle
        }
      }
    },
    plugins: {
      decimation: {
        enabled: false // Disable the built-in plugin; handle it upstream in the Worker
      }
    }
  }
});

🧠 Preventing Unbounded Memory Growth

To resolve your memory leak issue, make sure to prune the array tail. If your viewport duration is 60,000ms (1 minute), any data point where timestamp < Date.now() - 60000 must be unshifted or sliced off the tracking buffer array inside your data collection loop to avoid blowing up the Chrome engine's heap memory footprint.

[PrinkleMahshwari]

---

Hope this helps structuralize your streaming pipeline! If this architecture helps resolve your frame lag and stabilizes your memory leak issues, please consider marking this as the accepted answer to help other developers in the community find this layout structure quickly. 🚀