WinForms Chart GPU Performance:

Most WinForms charting comparisons start from a false premise: that WinForms is the legacy, slower sibling of WPF, and that any serious large-data charting belongs on WPF. For ProEssentials the opposite is true. The WinForms interface binds Direct3D directly to the window's device context (hDC), bypassing the render-to-texture and D3DImage compositor hop that WPF structurally requires — and in our testing that makes the native WinForms path roughly 5% faster end-to-end than the very same engine driving a WPF control.

This page explains why, compares the WinForms rendering architecture of the eight charting options developers actually evaluate, and points to four reproducible clone-and-run demos so every claim here can be verified rather than taken on faith. The headline is simple: on WinForms, ProEssentials renders 100 million lossless points in approximately 15 ms with zero data duplication, and it does so on the interface that is — by architecture — its fastest.

Reproduce every number on this page yourself. Four WinForms demos, clone and press F5:

The hDC Advantage: Why Native WinForms Beats WPF on the Same Engine

Every charting library that renders with the GPU on WPF faces an unavoidable architectural tax. WPF owns the screen through its own composition engine (the Media Integration Layer). A control cannot simply draw Direct3D onto the screen the way a native window can — WPF's compositor owns those pixels. To inject GPU content, the library must render its Direct3D scene to an off-screen texture, hand that texture to WPF through a D3DImage (or the newer composition interop), and let WPF's compositor blend it into the visual tree on the next compositor tick.

That round trip is not free. The finished GPU frame is copied into a shared surface, synchronized across the Direct3D and WPF rendering threads, and then composited a second time by WPF before it reaches the glass. Every frame pays a texture-copy and a compositor-sync cost that has nothing to do with how fast the chart itself was drawn.

The ProEssentials WinForms control has no such tax. As a standard System.Windows.Forms.Control it owns a real Win32 window handle and a real device context. Direct3D is coupled directly to that hDC, so the compute-shader-constructed frame is presented straight to the window — no render-to-texture, no D3DImage hand-off, no second composite. The same is true of the C++/MFC and Delphi/VCL interfaces, which tie to the hDC even more directly because there is no managed layer at all.

The practical result: across representative datasets the native WinForms interface measures roughly 5% faster end-to-end than the identical ProEssentials engine driving a WPF control. The compute shader, the zero-copy data path, and the on-demand frame model are byte-for-byte the same — the only difference is that WinForms skips WPF's compositor entirely. WinForms is not the compromise interface for ProEssentials. It is the fast one.

The WinForms Charting Landscape Is Not the WPF Landscape

When you move from WPF to WinForms, the competitive set changes and — more importantly — most rivals' high-performance technology does not come with you. Several libraries that market aggressive 'fast series' or GPU rendering expose those paths only on WPF, WinUI, or UWP. On WinForms they fall back to GDI+, to a feature-stripped fast view, or to nothing at all. Understanding which is which matters more than any single benchmark number.

ProEssentials: Direct3D Compute Shaders, hDC-Coupled

ProEssentials WinForms controls (PegoWin, PesgoWin, Pe3doWin, PepsoWin, PepcoWin) are standard System.Windows.Forms.Control descendants that use Direct3D compute shaders to construct the chart image entirely on the GPU. Thousands of GPU cores process every data point in parallel; the CPU never walks the array. The finished frame is presented directly to the control's hDC.

Large-data rendering is enabled with a few properties — PeData.ComputeShader = true plus the StagingBufferX/Y/Z flags — and data is supplied through UseDataAtLocation(), which stores a pointer to your existing array rather than copying it. There is no float-to-double conversion, no object-per-point allocation, and no managed loop over the data.

The pipeline runs on demand: it draws only when the data or viewport actually changes. An idle chart consumes zero GPU. This is the same engine, same shaders, and same zero-copy path used by the WPF control — but without WPF's render-to-texture compositor hop, which is why the WinForms path measures faster.

Reported throughput on an RTX 3090: 100 million lossless points constructed in ~15 ms, with end-to-end frame rates around 15 FPS including full 100M-point data transfer every frame — no resampling, no downsampling, no data reduction of any kind.

SciChart: No Native WinForms Control

SciChart is widely cited as the fastest WPF chart, but it has no native WinForms control at all. SciChart's own documentation states that WinForms is supported only 'through integration with WPF' — that is, by hosting the WPF SciChartSurface inside a Microsoft ElementHost.

This means a SciChart WinForms deployment inherits every characteristic of WPF — including the render-to-texture compositor path — plus the well-documented ElementHost interop caveats around mouse events, focus, and z-ordering. You are running a WPF control in a WinForms costume.

For a true native WinForms application — especially data-acquisition software with a Win32/MFC heritage — there is no first-class SciChart option. The category's headline performance name simply does not field a native WinForms entry.

LightningChart: Native, GPU — Continuous Loop

LightningChart is the strongest genuinely-native WinForms rival. It renders with low-level DirectX rather than GDI+ and markets very high capacity (older collateral cited up to 1 billion points; current marketing claims figures into the billions).

Its tradeoffs match the WPF page: a continuous DirectX render loop keeps the GPU active even when nothing changes, so idle dashboards still draw frames, and deployment historically required online activation with a reactivation fee — a real obstacle for air-gapped industrial and defense systems.

Lossless rendering at large scale depends on choosing the correct series type; the wrong type silently degrades performance by orders of magnitude with no compile-time warning.

DevExpress: SwiftPlot (WinForms-Only, Feature-Stripped)

DevExpress is interesting because its fast large-data view, SwiftPlotSeriesView, is WinForms-only — it does not exist in the WPF ChartControl. DevExpress markets the ability to visualize 'over 20 million points without preprocessing,' and its optional DirectX mode is up to 9× faster than GDI+ at UHD.

SwiftPlot achieves its speed by a 'lightened' generation algorithm that deliberately omits features available to other view types, and the underlying data model is still object-per-point. At 100M points that means allocating billions of bytes of DataPoint objects before rendering can begin.

It is a capable real-time view for the tens-of-thousands-to-low-millions range, but it is a CPU/GDI+-rooted path with optional DirectX — not a compute-shader engine, and not zero-copy.

Syncfusion: No WinForms Fast Series

Syncfusion markets 'Fast Series' (FastLineSeries, FastLineBitmapSeries) for high-volume data — but those exist only on WPF, WinUI, and UWP. On WinForms there is no fast-series path. Syncfusion's own support team logged a feature request to add fast series to the WinForms chart and stated there was no immediate plan to implement it.

Even on WPF, the fast path is CPU-based: FastLineBitmapSeries draws into a WriteableBitmap and renders a million points 'in a few seconds.' Syncfusion also discontinued its DirectX series. WinForms therefore relies on standard GDI+ rendering with no GPU acceleration.

Syncfusion remains a strong broad UI suite for business dashboards under ~100K points, but it is not a high-volume scientific WinForms charting engine.

ComponentOne FlexChart, Telerik, ScottPlot, MS Chart

ComponentOne FlexChart (Mescius/GrapeCity) is a capable native WinForms control with a GDI+ default and an optional Direct2D 'high-performance' mode — but its own published performance benchmark only tests from 100 to 30,000 points, three to four orders of magnitude below the 100M scale.

Telerik RadChartView is GDI+-based on WinForms; its hardware-accelerated Direct2D/Skia options are WPF-only. Telerik's own team has stated that 90,000 points 'is too much' for RadChartView and recommends aggregating/averaging data down before plotting — a lossy workaround.

ScottPlot is the dominant free/open-source option (CPU via System.Drawing then SkiaSharp). It relies on data decimation to a representative subset, and initialization of very large plots (10M+ points) takes 100+ ms; its maintainer notes that the managed-to-native marshalling of point arrays is the fundamental ceiling. The legacy Microsoft Chart (System.Windows.Forms.DataVisualization.Charting) is officially deprecated, GDI+-based, originated as a basic Dundas Chart, and is unsupported on modern .NET (5–8).

On-Demand vs Continuous Rendering — Same Story, WinForms Edition

The on-demand versus continuous distinction from the WPF page applies identically on WinForms, and it remains the most underappreciated factor in chart selection. ProEssentials draws only when data changes; LightningChart's continuous DirectX loop draws regardless. On a native WinForms control the on-demand frame is presented straight to the hDC, so the idle-GPU savings come with no compositor overhead when frames do occur.

On-demand rendering is not slower during active rendering — the compute-shader path is just as fast. The difference is what happens between frames: ProEssentials does nothing, while a continuous-loop library keeps the GPU and fan busy redrawing identical pixels.

How the GPU Compute-Shader Path Works

Without ComputeShader, the CPU walks each point sequentially on a single core to build vertex data. With PeData.ComputeShader = true, the GPU does this work across potentially 2,000+ cores in parallel. Measured impact on a 2.5M-point LiDAR cloud: click-to-first-paint drops from roughly 3 seconds of CPU vertex construction to essentially instant.

The StagingBuffer flags allocate GPU-accessible intermediate memory regions that allow efficient CPU-to-GPU upload without stalling the render pipeline during transfer. Comment the four lines out to take the slow CPU path on purpose — useful for before/after comparison:

// 3D scatter, GPU vertex construction, presented to the WinForms hDC
Pe3do1.PeData.ComputeShader  = true;
Pe3do1.PeData.StagingBufferX = true;
Pe3do1.PeData.StagingBufferY = true;
Pe3do1.PeData.StagingBufferZ = true;

The Bottom Line on WinForms Performance

On ProEssentials, WinForms is not a downgrade from WPF — it is the faster interface, because Direct3D ties to the window's hDC and skips WPF's render-to-texture compositor hop, for roughly a 5% end-to-end edge on the same engine. You get GPU compute shaders, on-demand rendering, lossless fidelity, and zero-copy loading, with 100M lossless points in ~15 ms.

Among the alternatives, SciChart has no native WinForms control (WPF-in-ElementHost only), Syncfusion has no WinForms fast series, Telerik tops out around tens of thousands of points before recommending aggregation, ComponentOne benchmarks only to 30K, ScottPlot decimates, and the Microsoft Chart is deprecated. LightningChart and DevExpress are the genuine native contenders — both capable, both carrying tradeoffs (continuous-loop power draw and activation; feature-stripped object-per-point fast view). For native WinForms, C++/MFC, and Delphi/VCL charting where data fidelity and large-scale performance matter, ProEssentials' hDC-coupled compute-shader engine is the strongest technical foundation available.

100M Points: Full Code

Side-by-side C# code showing exactly how each library handles 100 million data points.

Pricing & Support

5-year TCO comparison, support ticket limits, and who actually answers when you need help.

AI Code Assistance

How pe_query.py validates AI-generated chart code against the compiled DLL.

Technical References & Ground-Truth Sources

Every competitor claim on this page is sourced from the vendor's own documentation, benchmarks, or support statements. Verify them directly: