Q: How do you fix a ‘WebGL context lost’ event?

A webglcontextlost event usually means the browser's GPU process crashed, VRAM was exhausted, or the browser reached its limit of around 16 WebGL contexts per page, rather than a fault in your charting code. This is most commonly seen on integrated graphics adapters, such as older Intel HD GPUs, where a driver bug can cause the context to drop under load. A few steps help reduce or resolve it. By default, SciChartSurface.create() uses a single shared WebGL context across all charts in your application, which avoids hitting the browser's per-page context limit. If you’re using SciChartSurface.createSingle() for a large number of charts instead, switching to create() is often the fix. Also make sure your GPU drivers are up to date, since several context loss issues have been traced to driver bugs on specific hardware. SciChart.js includes logic to properly recover from a lost WebGL context where possible, so keeping your SciChart.js version current is worthwhile too.

Question 1

How do you fix a ‘WebGL context lost’ event?

Accepted Answer

A webglcontextlost event usually means the browser's GPU process crashed, VRAM was exhausted, or the browser reached its limit of around 16 WebGL contexts per page, rather than a fault in your charting code. This is most commonly seen on integrated graphics adapters, such as older Intel HD GPUs, where a driver bug can cause the context to drop under load. A few steps help reduce or resolve it. By default, SciChartSurface.create() uses a single shared WebGL context across all charts in your application, which avoids hitting the browser's per-page context limit. If you’re using SciChartSurface.createSingle() for a large number of charts instead, switching to create() is often the fix. Also make sure your GPU drivers are up to date, since several context loss issues have been traced to driver bugs on specific hardware. SciChart.js includes logic to properly recover from a lost WebGL context where possible, so keeping your SciChart.js version current is worthwhile too.

Question 2

Can I use Wasm?

Accepted Answer

Yes, and with SciChart.js you already are. SciChart.js is built on WebAssembly (Wasm), compiled from the same in-house C++ engine used across SciChart's platforms, paired with WebGL for rendering. When you initialize a chart, SciChart.js fetches the required .wasm file, either from SciChart's CDN by default or from your own server for offline deployments, so it is worth including this file in your build or deployment pipeline. Since Wasm memory is not garbage collected the way JavaScript memory is, remember to call .delete() on any IDeletable objects when a chart is no longer needed to avoid a memory leak.

Question 3

How do you change the data resolution?

Accepted Answer

The ResamplingMode controls the fidelity of the line plotted against the data. Adjusting the data density can reduce fidelity but improve rendering performance significantly, since fewer points need to be drawn for the same visible range. If you’re optimizing for speed on dense, real-time datasets, you can combine this with a lower StrokeThickness and disabling anti-aliasing for a further performance gain.

Question 4

What’s the best way to handle a drop in frame rate on mobile?

Accepted Answer

If you notice a drop in frame rate on higher-density screens, consider reducing the number of visible data points through resampling, simplifying series styling, or limiting the render area, rather than lowering DPI itself. Testing across a representative range of iOS and Android devices, as SciChart does with every release, is the most reliable way to confirm real-world performance on mobile.

Question 5

How much DPI is safe for mobile?

Accepted Answer

There is not a single DPI figure that works for every device, due to screen density, GPU capability, and available memory vary considerably across phones and tablets. Rather than targeting a fixed DPI value, it’s best to render at the device's native resolution and scale factor, then profile FPS and memory on your actual target devices, including older or lower-spec models, rather than relying on a simulator alone.

Question 6

How can you test graph visualization performance before production?

Accepted Answer

Before shipping, it’s worth profiling your chart under conditions that resemble your real workload rather than just a small demo dataset. Test with the volume, update frequency, and number of series you expect in production, and monitor FPS and memory usage as you do.

Question 7

What signals indicate a GPU/Driver is limiting features?

Accepted Answer

A few signs point to the graphics adapter or its drivers as the bottleneck rather than your application code. Look out for:

The GPU Compatibility Test report shows the adapter is blacklisted, or that only Direct3D 9 (not Direct3D 11) initializes successfully.
A warning that Video RAM is below the recommended threshold, which triggers an automatic downgrade to software rendering or Direct3D 9 mode.
Visual glitches, unexpected crashes, or a failure to load charts, particularly on laptops with dual GPUs where the wrong adapter is being used.
Timeout Detection and Recovery events from the operating system, which can indicate the GPU's compute capability is too limited for the workload.

If you see these signals, check your video adapter with DXDiag.exe, confirm the correct GPU is active on dual-GPU machines, and update graphics drivers where possible.

Question 8

Can SciChart handle real-time updates at 60 FPS or more?

Accepted Answer

Yes. SciChart’s high-performance graphics engine can comfortably handle data rendering at 60 FPS, or even more!

Question 9

How many data points can I realistically render?

Accepted Answer

Over the years, we have vastly improved our data rendering performance. With our WPF chart library, you can achieve 1-billion data points with sorted data and around 10,000,000 points with unsorted data. With our JavaScript chart library, you can load 1-million data points in under 15 milliseconds.

Question 10

Should I be using SVG, Canvas, or WebGL for large data sets?

Accepted Answer

SVG based JavaScript chart libraries are good when you’re rendering less data but very flexible for styling. Canvas 2D charts are faster but get quite slow as they reach 10,000 datapoints. WebGL based chart libraries offer the fastest approach to data rendering using hardware acceleration. If you want to render over 100,000 data points you will need to use WebGL.

Question 11

Is there a charting library that can handle 100k+ points without lag?

Accepted Answer

Yes! You may have tried other libraries in the past and struggled to get past the 100,000 data mark without experiencing lag or freezing UIs. However, with SciChart’s accelerated graphics engine, this isn’t a problem! Check out our one million data points demo.

Question 12

What optimizations does SciChart use?

Accepted Answer

SciChart uses WebGL and data resampling which downsizes the data points. Redraw throttling also occurs automatically. Check out this documentation on sub-charts for SciChart.js.

Performance & Scalability