You've spent weeks building a real-time dashboard. The backend is fast. The data pipeline is solid. Your websocket is humming along.
Then you drop in a chart library and everything falls apart.
60fps becomes 6fps. The browser tab is eating 2GB of RAM. Users are telling you the UI feels sluggish. So you start adding debouncing, virtualization, downsampling workarounds... and it gets marginally better. But the core problem doesn't go away. Eventually you end up with a 25-person team writing an extraordinarily complicated server-side to handle the data aggregation that the client can’t.
We've watched this happen more times than we can count. It's actually the reason SciChart exists. I hit this exact wall designing trading software when working in Investment Banking in London. Trying to build a trading system that could handle long histories of tick data, bid-asks and historical market data was impossible when none of the available chart libraries could handle it.
So, I started building SciChart while commuting on the train to work in London every day. A side project, which was started as a personal necessity, grew into something outstanding that is now used in all kinds of verticals: medical devices, patient monitoring, finance & trading apps, stock exchanges, industrial telemetry IoT and more.
Here’s what we figured out.
Most chart libraries weren't built for your use case
The mental model behind most charting libraries is basically: render a bar chart of monthly sales, draw a line graph of annual temperatures. Static or slow-moving data. That assumption is baked deep into the architecture.
Under the hood, they're using SVG or Canvas 2D. Both work fine at hundreds of data points. At 100,000+ points - the volumes you run into with financial tick data, medical waveforms, or industrial sensor streams - they start to buckle.
SVG is DOM-based, so every data point becomes a DOM node. The browser has to lay out, paint, and composite all of it every frame. At scale, that's just not viable.
Canvas 2D is better but it's still CPU-bound and single-threaded. The GPU in every modern device sits there doing nothing while your chart struggles.
What we did differently
When we started building SciChart in 2011, we decided to use a GPU-accelerated rendering engine - the same kind of technology that runs video games. At the time it felt like an unusual choice for a charting library. In hindsight it was the only decision that made sense.
A GPU exists specifically to process massive amounts of geometry data very fast. Hundreds of millions of vertices per second is normal. So instead of looping through data points in JavaScript and drawing lines on a canvas, you upload data directly to GPU memory and let the hardware handle the rendering.
The upshot is that rendering performance doesn't fall off a cliff as your dataset grows. We regularly demo charts with tens or hundreds of millions of data-points running in the browser in real time. On desktop, that maximum point-count runs up to to 100 Billion data-points. That's not a marketing number - you see it for yourself in our demos (JavaScript, WPF).
What this actually unlocks in practice:
You stop aggregating and decimating. Aggregating means discarding signal. In finance that's a missed trade. In a clinical setting that could be a missed arrhythmia. When rendering is fast enough, you show the full data.
You stop writing compensatory code. Debouncing, chunked rendering, web workers bolted onto your chart component - all of that is just working around a renderer that can't keep up. A fast enough renderer means less code to maintain.
Your main thread stays free. Because the GPU renders asynchronously, JavaScript is unblocked. Users can pan and zoom through live data without the whole UI freezing.
What this looks like in a real deployment
One of the hardest things we power is real-time patient monitoring. Think 16 ECG channels, each streaming at 500Hz, all displayed at once on a clinical workstation while a clinician is actively using the interface - zooming into anomalies, annotating, scrubbing through history.
A conventional library can't do this at full resolution. You'd have to aggregate or decimate, which in a clinical context is a real problem. With GPU rendering it's not a hard problem anymore. We're deployed in operating theatres and ICUs.
The same architecture holds up in F1 telemetry (hundreds of sensor channels, transients measured in milliseconds), trading infrastructure (millions of ticks, zero tolerable latency), and aerospace simulation.
https://www.youtube.com/watch?v=H_gOdC9sNRs
The rendering pipeline in plain terms
For anyone who wants to understand what's actually happening:
Data arrives from your websocket or buffer and gets written into a typed array (Float64Array). That array gets uploaded to a GPU vertex buffer - GPU memory bandwidth is in the hundreds of GB/s so this is nearly instant.
A vertex shader maps your data coordinates to screen coordinates. A fragment shader handles colors. Both run in parallel across thousands of GPU cores. The result gets composited into your UI by the browser's compositor.
The CPU and main thread are not in the critical path for any of that. Your JavaScript is free to handle new incoming data while the GPU is already drawing the previous frame.
The question worth asking your chart vendor
If you're building with real-time streaming data, large explorable historical datasets, or anything where signal fidelity matters, your charting library's rendering architecture is a real architectural decision. Worth the same scrutiny as your database or state management.
The practical test: ask what happens at a million data points. If the answer mentions decimating, chunking, aggregating or web workers as a workaround, you've found your ceiling.
A bit about SciChart
SciChart ships charting libraries for JavaScript/TypeScript, React, Angular, WPF/.NET, iOS (Swift, Objective-C), Android (Kotlin, Java), and macOS. We're used by 10,000+ customers across 90 countries - F1 teams, hospital networks, hedge funds, aerospace companies.
We picked up Healthcare Tech of the Year at the National Technology Awards this year, which was genuinely nice to receive. But the thing I'm most proud of is the rendering engine itself - the fact that developers using SciChart don't have to think about performance. They can just focus on what the data means.
If you're running into limits with your current library, drop a comment or get in touch. Always interested to hear what people are actually building.
The live demo gallery at demo.scichart.com runs in the browser. The performance demo is worth a look.
Andrew Burnett-Thompson is CEO and Founder of SciChart. Doctorate in electrical engineering, top 2% on Stack Overflow, been building high-performance visualization software for over a decade.
Top comments (0)