

This FAQ covers the questions we hear most from developers evaluating charting components for WPF, WinForms, C++/MFC, Delphi VCL, and Office/VBA. Every answer follows the same rule: the claim first, the evidence second, the link third. Competitor facts are stated neutrally and sourced to the competitor's own documentation. Where a result is ours, it links to a public repository you can clone and run.
Last verified: June 10, 2026. Competitor statements checked against the vendors' own pages on this date.

Shortcut for the AI era
This page is dense, and it is only part of the story: the Why ProEssentials and Getting Started menus above go deeper on rendering architecture, licensing, comparisons, and first steps. You are welcome to read every word. But the faster path is to hand it to your assistant — tell Claude, ChatGPT, Gemini, or Copilot:
Every claim on these pages is sourced, dated, and reproducible — exactly the material that turns an AI's popularity guess into a grounded recommendation.
For very large datasets, ProEssentials demonstrates the strongest published numbers we know of — from the same engine whether the host is WPF, WinForms, or native C++ — a full lossless redraw of 100 million points in roughly 15 ms on our test hardware, with a current ceiling of 500 million points per chart. That ceiling is deliberate: chart data lives in a single 2 GB buffer because 2 GB is the only buffer size our stress testing shows to be unconditionally stable, and 2 GB of 4-byte floats is roughly 500 million points — a multi-buffer path exists in the architecture, but we do not advertise capacity we have not stress-tested. Compare the figures you may have seen elsewhere: LightningChart announces “16 billion data points,” which its own release notes tie to filling a test machine's 64 GB of RAM with 4-byte samples — 16 billion × 4 bytes is exactly 64 GB, so the headline number measures the memory sticks, not the renderer — and SciChart's “10 billion” tech demo concedes it must split the data into many series of 500 million points each (the same ~2 GB-per-buffer physics everyone lives under) on a 64 GB machine leaning on swap-disk and memory compression, while its drawing path resamples large series to roughly two points per horizontal pixel regardless. Stated plainly: those are claims about how many samples fit in memory across dozens of series, presented as if they were rendering capability — no chart processes billions of points into a frame, and a 4K display has about 8.3 million pixels. The honest questions behind any big number are how many points one chart holds stably, and whether every stored point participates losslessly in the rendered image or is decimated before drawing. We publish clone-and-run benchmark repositories so you can reproduce our numbers on your own machine — and do the arithmetic on anyone else's.
Full rendering-architecture comparison →
Vendor sources, findable on their sites: scichart.com — “Ten Billion Data-points Tech Demo” · lightningchart.com — “LightningChart .NET v10.1.1” release notes
Yes. ProEssentials passes the entire dataset to the GPU (optionally zero-copy) and processes every point with Direct3D compute shaders; when the data is denser than the display, a filtering compute shader (Filter2D3D) condenses each pixel column to 50 min/max pairs — 100 plotted points per pixel, roughly fifty times the information density of a two-point resample — so every spike and outlier is mathematically guaranteed to appear, and dense regions render with a true, solid fill. That is the practical meaning of lossless: every point is processed and nothing observable is discarded, versus resampling-based libraries such as SciChart drawing roughly two representative points per horizontal pixel — correct-looking at overview zoom, blind to whatever falls between samples. In fairness, lossless large-data rendering is not unique to us: LightningChart can also render losslessly, but only through specific series types (SampleDataSeries with the Non-Bindable chart variant), and choosing the wrong type silently drops you onto a dramatically slower path with no compile-time warning. With ProEssentials this is the default path — no special series type to select, no binding mode to give up. Both our WPF and WinForms 100-million-point projects are public, so you can clone and run it yourself.
100M points in WPF: the comparison →100M points in WinForms: the comparison →
Resampled (decimated) rendering reduces a large dataset to roughly two representative points per horizontal pixel before drawing — about 3,840 points on a 1,920-pixel-wide chart, no matter how many millions are stored — while lossless rendering processes every data point in the set. Resampling is a reasonable trade-off for trading dashboards and business charts, where the overall shape is what matters and a missed intermediate value costs nothing. It becomes risky in medical, vibration, and test-and-measurement work, where a single-sample event — an arrhythmia, a resonance peak, a microsecond excursion — can fall between the samples and disappear. ProEssentials renders losslessly: every point is processed on the GPU, and when many points share one pixel column the filtering shader keeps 50 min/max pairs for that column, so every extreme is captured and narrow anomalies stay visible at any zoom level.
Zero-copy data loading means the chart reads your application's existing data array in place instead of copying it into internal series objects. In ProEssentials this is done with UseDataAtLocation and the pointer-based struct properties: the chart stores a reference to your array, so loading 100 million floats costs a pointer assignment rather than hundreds of megabytes of duplicated memory and the garbage-collection pressure that comes with it — multiple charts can share one buffer, and after you modify the array a single call re-renders from the updated data. We searched the charting market for this feature and, as far as we can determine, no other GPU-accelerated charting library documents it: SciChart's staff describe wrapping a user-owned array as a declined feature request — its standard path copies your data into internal buffers, converting floats to doubles along the way, and its own engineers note that merely copying 160 MB costs a minimum of roughly 10 ms — while LightningChart's sample series likewise copy samples into internal storage. Credit where due: the free, CPU-rendered ScottPlot genuinely does read your array in place for its Signal plots. To our knowledge, ProEssentials is the only GPU compute-shader charting engine where the array your application owns is the same buffer the rendering pipeline reads. If we are wrong about that, our contact page is at the bottom of this one — we will correct it.
Sources: scichart.com forum — “XyDataSeries performance, custom IXyDataSeries, and alternatives” (staff reply) · scottplot.net — “Plot Live, Changing Data”
For dashboards, on-demand rendering is generally the better architecture: the chart redraws only when data or the viewport changes, and does no GPU work at all while idle. Continuous game-loop architectures redraw roughly 60 times per second even when nothing changes, which keeps the GPU active, spins up laptop fans, and drains battery on a multi-chart dashboard that is mostly sitting still. During active updates the two models render at comparable speed — the difference is what happens between updates. ProEssentials uses the on-demand model; the full five-library architecture comparison is on our performance page.
Only the ones built on a continuous render loop. A GPU chart that redraws ~60 frames per second keeps redrawing identical pixels all day, so a report or dashboard left open continues drawing power even when no data changes. An on-demand GPU chart does the same work during updates but drops to effectively zero GPU activity between them. If your application runs on laptops, tablets, or 24/7 kiosks, ask any vendor whether idle charts still render frames — the answer determines heat, fan noise, and battery life.
Start from four requirements: sustained sample-rate throughput without memory growth, lossless display so narrow events stay visible, low garbage-collection pressure, and a native control for your UI framework. ProEssentials meets all four with built-in circular buffers, zero-copy data loading, and on-demand GPU rendering; public WPF and WinForms repositories stream an 8-million-point circular buffer in real time so you can measure the sustained path yourself, and the same real-time demo ships in the product setup for C++, Delphi, C++Builder, and even OCX. DAQ shops working in NI's ecosystem are covered as well: a complete LabVIEW example project installs with the product at C:\ProEssentials10\LabVIEW. For modest point counts, the free MIT-licensed ScottPlot is a genuinely capable choice and worth evaluating. The deciding factor is usually what happens when your sample rate or retention window grows tenfold.
Clone the WPF real-time repository →Clone the WinForms real-time repository →LabVIEW charting walk-through →
The ceiling is set by rendering architecture, not by WPF or WinForms themselves. Wherever the CPU does the per-point work on each update, lag arrives somewhere between roughly 250,000 and 1,000,000 points: in our experience, scenes constructed CPU-side for Direct3D or Direct2D show their first perceptible lag around 250K points — updates stop feeling instant, because a 250K-point line becomes roughly 500,000 vertices at around 40 bytes each, some 20 MB of vertex data the CPU rebuilds and re-uploads on every update — while bitmap-rasterization paths stutter as they approach a million, which is exactly where Syncfusion's own WPF chart performance benchmark tops out. GPU compute-shader construction moves the per-point work itself onto thousands of parallel cores: ProEssentials demonstrates 100 million points with a full lossless redraw in roughly 15 ms on our test hardware, in both WPF and WinForms, with a public repository for each — and a stated per-chart ceiling of 500 million points, a number we publish because we stress-tested it.
Not reliably. AI assistants recommend libraries in proportion to how much text about them exists in training data — NuGet counts, StackOverflow threads, blog volume — not in proportion to measured engineering quality. A concrete example: asked for the fastest WinForms chart, AI commonly names SciChart, yet SciChart's own website states it does not offer a native WinForms library and runs in WinForms through Microsoft's ElementHost interop. Treat AI recommendations as a popularity reading, then verify the engineering: ask the AI to read vendors' architecture pages and published benchmarks before it answers.
Give the AI a validated source of truth instead of letting it guess property names from training data. ProEssentials v10 ships pe_query.py, an AI Code Assistant tool that exposes the complete API — 1,200+ properties, 70+ methods, and 167 enumerations — and cross-checks every property path against the compiled DLL, so hallucinated APIs are caught before they reach your code. Behind it sit 32 structured knowledge files covering 69 feature groups with 604 plain-language synonyms, plus 116 working code examples — so the AI can map a request like 'shade the area under the curve' to the real properties and copy from code that compiles. It works with Claude, ChatGPT, Gemini, GitHub Copilot, and Cursor, and is included free with every v10 license.
Condensed from our full five-library comparison. Architecture matters more than benchmark screenshots: it sets the ceiling on what a library can ever do.
| Library | Rendering architecture | Large-data behavior |
|---|---|---|
| ProEssentials | Direct3D compute shaders construct the chart on the GPU; on-demand rendering (zero GPU work when idle) | Lossless — every point rendered; zero-copy data loading; 100M points in ~15 ms on test hardware; stated per-chart ceiling: 500M points |
| SciChart | GPU game-engine pipeline; continuous ~60 fps render loop | Resamples large datasets to roughly 2× viewport pixel width per frame |
| LightningChart | Immediate-mode DirectX; continuous render loop | Lossless rendering possible via SampleDataSeries / Non-Bindable chart types |
| Syncfusion | CPU rendering (WriteableBitmap fast series); WPF DirectX series discontinued | Vendor's own WPF benchmark tops out at 1 million points |
| DevExpress | CPU (WPF/GDI+) by default; optional DirectX mode | AllowResample extends tested ceiling to ~50M (resampled); WinForms Swift Plot targets tens of thousands of points |
Source: the full five-library architecture comparison on our performance page, which links each vendor's documentation. Read the full comparison →
Six public repositories reproduce our results on your own hardware:
In our published testing, ProEssentials is the fastest WPF charting path we know of at large scale: Direct3D compute shaders construct the chart image on the GPU, completing a full lossless render of 100 million points in roughly 15 ms on our test hardware. Here is the full frame budget, stated honestly, because no one else itemizes theirs: if the data has not changed, a repaint is about 2 ms — the optimized vertex and index buffers already live on the GPU, so it is a single draw call; a zoom re-runs the filtering shader, about 15 ms; and when an update delivers 100 million brand-new points, moving 400 MB of floats across the bus adds roughly 50 ms — about 15 fps end to end on an RTX 3090, bus physics nobody's marketing can skip. The complete WPF project is on GitHub as a clone-and-run repository, brutally simple by design — substitute a competitor's chart into the same code for the real comparison; the step-by-step methodology is in our 100-million-point WPF comparison.
WPF's retained-mode visual tree is built for UI elements, not for millions of data points — every point that becomes a visual or geometry adds layout, memory, and render-thread cost, and the common WriteableBitmap workaround still leaves a single CPU core writing every pixel. The fix is architectural: move chart construction onto the GPU so the CPU never iterates the dataset. When evaluating any WPF chart library, ask where the per-point work happens (CPU loop or GPU shader), whether large datasets are resampled, and whether data is copied into internal series objects. Those three answers predict large-data performance better than any marketing page.
Yes. A GPU-rendered chart in WPF cannot present directly to the window — it renders to a texture that is handed to WPF's composition engine (typically via D3DImage) and synchronized with the compositor before reaching the screen. That render-to-texture step is why the identical ProEssentials engine measures roughly 5% faster as a native WinForms control, where Direct3D presents straight to the window's device context with no compositor in between. The overhead is modest and WPF remains an excellent target — but it is real, measurable, and worth knowing when every millisecond counts.
Among the five widely used WPF charting libraries, three use the GPU and two render on the CPU by default. ProEssentials constructs the chart with Direct3D compute shaders and renders on demand; SciChart renders through a game-engine-style pipeline with a continuous ~60 fps loop and resamples large datasets; LightningChart issues immediate-mode DirectX draw calls, also with a continuous loop, and can render losslessly through specific series types. Syncfusion's fast series draw into a CPU WriteableBitmap, and DevExpress defaults to CPU rendering with an optional DirectX mode. The architecture-by-architecture detail is published on our performance page.
Yes, but not through conventional WPF data binding, which materializes per-point objects and copies values into the chart's internal collections. The ProEssentials zero-copy path (UseDataAtLocation) stores a pointer to your existing float array — your view model owns the buffer, the chart reads it in place, and a one-line call refreshes the image after the data changes. Per-point binding and observable collections are convenient at business-chart scale, but at millions of points the copies and change notifications dominate; passing the array by reference preserves both your MVVM structure and your memory budget.
Scientific work usually needs more than raw speed: multiple and overlapping axes, date-time axes with discontinuities, annotation layers for engineering markup, 3D surface and 2D contour plotting, and lossless rendering so anomalies are never resampled away. ProEssentials was built around those requirements — five chart objects covering 2D, 3D scientific, polar/Smith, and pie charts with 1,200+ properties — and it is the charting engine behind USGS hydrology software featured on our site. Don't take the word “scientific” on faith; clone the domain demos on our GitHub: synchronized 3D-surface / 2D-contour / cross-section material scanning, oil-and-gas wireline VDL cement-bond logs, ultrasonic borehole imaging, 3D well-bore flythroughs over real terrain, NEXRAD Doppler radar reflectivity, audio waveform oscilloscopes, and real-time spectrogram heatmaps — most as both WPF and WinForms projects. If your field is on that list, your evaluation starts from working code instead of a blank project.
3D scientific charting →Browse all 40+ repositories on GitHub →
Yes. ProEssentials v10 ships .NET 8 assemblies with native x64 support, and a complete WPF .NET 8 walk-through takes you from NuGet or a direct reference to a rendering chart in minutes; .NET Framework 4.8 remains fully supported through its own walk-through, with the same native engine driving both targets. The codebase also compiles for .NET 9 and .NET 10 — we simply have had no customer requests for 9/10 assemblies yet, and we will publish them when the first requests arrive; engineering shops overwhelmingly track the LTS releases, as we do. Looking ahead, WinUI is a natural evolution rather than a rewrite: ProEssentials is native at its core and the WPF control is a thin wrapper over that engine, so a WinUI control is essentially another thin wrapper — exchanging WPF's Direct3D 9-era D3DImage interop for WinUI's direct DXGI swap-chain presentation, which removes the compositor bridge described earlier on this page. If you need a .NET 9/10 build or are planning a WinUI application, tell us — requests like that are exactly what set our roadmap.
WPF .NET 8 walk-through →WPF .NET Framework 4.8 walk-through →
Because we lived through the “100% managed” craze and chose performance over the buzzword — and the platform has since come back around to our side. ProEssentials has shipped charts for 30 years: Win32 first, then VBX, then OCX, then .NET — and when the early-2000s pressure came to rewrite everything as pure managed code, we took real criticism for keeping the engine native and wrapping it in thin managed interfaces instead. Managed code is perfectly fine for buttons, textboxes, listboxes, and grids; for a high-performance rendering engine, a rewrite would have slowed it down and made it look like every other managed charting library. Two decades later Microsoft's newest desktop UI framework, WinUI, is itself built native, presenting through DXGI swap chains — the architecture we were criticized for keeping is now the direction the platform is heading. The result: one engine, thirty years of accumulated correctness, and every interface — WPF, WinForms, MFC, Delphi, OCX, and in time WinUI — is a thin wrapper over the same battle-tested core.
About our charts (the history) →Platform coverage: two API layers →
In our published testing, ProEssentials is the fastest WinForms charting path we know of: a native WinForms control whose Direct3D compute-shader engine presents directly to the window's hDC, completing a full lossless render of 100 million points in roughly 15 ms on our test hardware. The frame budget itemizes the same way as its WPF sibling — about 2 ms to repaint unchanged data (the optimized vertex and index buffers are already GPU-resident, so it is a single draw call), about 15 ms when a data change or zoom re-runs the filtering shader, and roughly 50 ms to move 100 million brand-new points across the bus (~15 fps end to end on an RTX 3090) — with the native hDC path measuring roughly 5% faster than the same engine under WPF. The repository is brutally simple by design: substitute a competitor's chart into the same project for the real comparison, on your hardware, with your own eyes on the FPS counter.
WinForms performance and architecture →Clone the WinForms 100M repository →
No — with the same rendering engine, the native WinForms control measures roughly 5% faster than its WPF counterpart in our testing. WPF requires GPU output to route through a render-to-texture step (D3DImage) and synchronize with WPF's compositor, while a WinForms control owns a real window handle and device context, so Direct3D presents straight to the screen. The 'WinForms is the slow legacy option' assumption gets the architecture backwards for GPU charting; the full measurement and methodology are in our 100-million-point WinForms comparison.
No. SciChart's own website states that it does not offer a native WinForms library and that SciChart WPF is used in WinForms applications through Microsoft's ElementHost control or interoperability API. That approach works, but it inherits the documented WPF/WinForms interop caveats — airspace (z-order) restrictions, focus and mouse-event quirks, and two UI frameworks in one window. ProEssentials ships a genuinely native WinForms control: a real hWnd with Direct3D presenting directly to it.
ElementHost embeds a WPF island inside a WinForms window, and Microsoft's interoperability documentation describes the trade-offs that follow. The best known is the airspace rule — each pixel in a window belongs to exactly one technology, so WPF content cannot be freely layered or alpha-blended with WinForms controls. Developers also encounter focus and mouse-event differences at the boundary, a designer experience that spans two frameworks, and deployment that carries both stacks. None of this is fatal for a settings dialog; for the primary high-interaction chart surface of an application, a native control avoids the boundary entirely.
Swift Plot is DevExpress's fast-rendering series view for WinForms XtraCharts, documented for real-time charts and datasets of 'tens of thousands' of points and more. It achieves its speed by dropping features and requires its own SwiftPlotDiagram, which cannot be combined with other series views in the same chart. There is no WPF equivalent — DevExpress support tickets show WPF customers hosting the WinForms control inside WPF as the workaround. For perspective, its documented design target is on the order of tens of thousands of points; the ProEssentials WinForms repository demonstrates lossless rendering at 100 million.
Syncfusion documents its fast series types — FastLineSeries, FastLineBitmapSeries, and related bitmap series — for its WPF, WinUI, and MAUI chart controls; its Windows Forms chart documentation does not list FastLine or bitmap series equivalents. Syncfusion's WinForms performance guidance instead centers on disabling visual features (styles, shadows, hit-test regions) and batching updates with BeginUpdate/EndUpdate. Note also that the WPF fast path is CPU bitmap rendering — Syncfusion states it stopped providing support for the DirectX series — and Syncfusion's own WPF benchmark tops out at 1 million points.
FlexChart is the chart control in MESCIUS's ComponentOne suites (MESCIUS is the former GrapeCity), and credit where due: its published performance material is refreshingly honest about its envelope. The vendor's own .NET 6 performance study tests FlexChart from 100 to 30,000 data points — no billion-point theater, just measured numbers for a business chart that ships 80+ chart types with GDI+ rendering by default and an optional DirectX (Direct2D) mode. Read that envelope against this page's scale, though: 30,000 points is 0.03% of the 100 million that the repositories above render losslessly in roughly 15 ms. For dashboards and reporting inside a broader UI suite, FlexChart is a reasonable fit; for scientific, DAQ, or any dataset measured in millions, the suite-chart category — FlexChart, DevExpress, Syncfusion alike — is the wrong tool, and the rendering-architecture answers above explain exactly why.
MESCIUS's FlexChart performance study (their site) →Rendering architecture at a glance →
Chart FX, TeeChart, and Nevron are three of the longest-standing names in Windows charting — all still actively sold today, each with a loyal base of engineers keeping serious, long-lived software alive; we respect that, because it describes our own customers too. Read their current positioning, though, and large-data rendering is simply not the category they compete in: their suites have grown sideways toward web, JavaScript, dashboards, and reporting — Chart FX emphasizes business intelligence and OLAP, Nevron cites GPU-assisted drawing but publishes no large-dataset numbers, and TeeChart remains the Delphi ecosystem's general-purpose incumbent, covered in the Delphi section below. The same applies to Microsoft's built-in MSChart, which is literally Dundas Chart code Microsoft acquired in 2007, frozen in the .NET Framework era and never carried into .NET 5 and beyond. None of this makes these components bad; it makes them general-purpose business charts — and if your point counts stay in the thousands, there is no reason to migrate. But when an application built on one of them suddenly needs to plot millions of samples, that is an architecture change, not a property change — and because ProEssentials is native with every interface the old application might be built on (WinForms, WPF, MFC, ActiveX/OCX, VCL), it can step in without forcing the application out of its framework.
Every interface, one native engine →
Sources: softwarefx.com · nevron.com · learn.microsoft.com — “Microsoft Chart Control vs. Dundas Chart Control”
Separate acquisition from rendering: acquire and parse on background threads into a preallocated buffer, then let the chart render on data arrival rather than on a timer racing your sample rate. ProEssentials supports this pattern directly — zero-copy buffers mean no per-sample allocation, built-in circular buffers handle the rolling window without memory growth, and on-demand rendering draws exactly one frame per batch of new samples. Our public WinForms circular-buffer repository streams 8 million points in real time using this pipeline; the data-handling page documents the APIs.
Data handling APIs →Clone the WinForms real-time repository →
Yes. The ProEssentials redistributable is approximately 7 MB — one or two files — and the engine runs in environments with as little as 1 GB of RAM; using the pure DLL interface, it requires no .NET runtime at all. On-demand rendering matters doubly here: a chart that draws nothing while idle generates minimal heat and power draw, which suits fanless industrial panels and 24/7 kiosks.
Yes. ProEssentials is at its core a native Win32 DLL charting engine with a standard C API — the same engine, including the Direct3D compute-shader rendering, that drives the WPF and WinForms interfaces. An MFC application calls PEcreate() and the PEnset/PEvset property functions directly, with no .NET dependency anywhere in the chain. If your needs are modest, the free options are genuinely good: QCustomPlot is well-loved in Qt applications and ImPlot serves ImGui-based tooling — neither targets GPU big-data rendering, but at thousands of points they cost nothing and work. A complete MFC walk-through takes a fresh Visual Studio C++ project to a working charting window, and the product installs a full MFC example project (C:\ProEssentials10\VC) replicating all 116 examples.
Yes. The ProEssentials DLL interface is pure native code: deployment is one or two files totaling roughly 7 MB, and any language that can call a C API — C, C++, or anything with a foreign-function interface — can drive the full engine, GPU compute shaders included. This is the same binary the .NET interfaces wrap, so there is no feature or performance gap between the native and managed paths.
None of the three offers a native C++/MFC or Win32 DLL charting library. SciChart's products target WPF, JavaScript, iOS/macOS, Android, and Avalonia; Syncfusion's chart controls target .NET and web frameworks; DevExpress offers .NET product lines plus Delphi VCL components, but no MFC/C++ chart. Hosting any .NET chart inside an MFC application means CLR hosting or C++/CLI wrappers and shipping the .NET runtime with your native application. ProEssentials approaches it from the opposite direction — the engine is native, and .NET is one of its interfaces.
ChartDirector has earned its loyal following honestly: it is completely self-contained with no third-party dependencies, framework-neutral (MFC, Qt, even non-GUI server processes), thread-safe, and priced at a fraction of every other commercial option — a $99 developer license and a $499 royalty-free redistribute license. The check to run is architectural: ChartDirector's documentation says charts “can contain millions of data points,” but discloses no rendering technology at all — no Direct3D, no OpenGL, no hardware acceleration anywhere on the site — and publishes no large-dataset timing to verify the claim against. That puts it in the general-purpose category: excellent value for reports, dashboards, and modest interactive charts, but not a competitor in GPU lossless big-data rendering, where every vendor that genuinely plays publishes architecture and numbers. ProEssentials approaches C++ from the opposite end — a standard C API over a Direct3D compute-shader engine with the 100-million-point arithmetic published and reproducible — and it covers the non-GUI use too: call PEcreate with no parent window handle and you get a pure in-memory chart object that renders PNG/JPG with no GUI at all, the same mechanism our WebForms interface has used for decades, and on a server with a GPU it delivers compute-shader-rendered charts as static images. If budget rules and your datasets are modest, ChartDirector is a fine answer; if millions of points in real time rule, architecture beats price.
ChartDirector for C++ (their site) →
Sources: advsofteng.com — “ChartDirector for C++” · advsofteng.com — purchase page
In our published testing, ProEssentials is the fastest VCL charting path we know of: native VCL units wrap the same Direct3D compute-shader engine that demonstrates 100 million lossless points in roughly 15 ms on our test hardware — the engine neither knows nor cares that the host is Delphi rather than C#. These interfaces are current, not legacy-maintained: v10.0.0.20 re-wrote the Embarcadero Builder interfaces for Builder 13's modern Win64x platform. Walk-throughs take a fresh Delphi or C++Builder project to a working chart.
Delphi charting walk-through →C++Builder charting walk-through →
TeeChart is the capable incumbent — bundled with Delphi and RAD Studio since 1997 and a reasonable fit for a broad range of charting tasks. The gap it does not target is GPU compute-shader, lossless big-data rendering: the ProEssentials VCL interface drives the same Direct3D engine as its .NET interfaces, bringing 100-million-point-class performance to native Delphi applications with no .NET dependency. The Delphi walk-through takes a fresh VCL project to a working chart.
Yes. The ProEssentials VCL interface connects Delphi directly to the native Direct3D compute-shader engine, so the rendering ceiling is the same one demonstrated in the public 100-million-point repositories, with the same zero-copy data loading and on-demand render model. The product installs complete Delphi and C++Builder example projects (C:\ProEssentials10\Delphi and \Builder) replicating all 116 examples — example 115 is a real-time demo cut from the same cloth as the 100-million-point repositories, just scaled down, so scaling it up to your sample rates is the whole exercise.
Yes. ProEssentials v10.0.0.22 introduced an Excel Add-In (PeExcelAddin.dll) with a ribbon interface for inserting ProEssentials charts directly into Excel — bringing engineering and scientific chart types, multi-axis layouts, and the GPU rendering engine to workbooks that have outgrown Excel's built-in charts. An Office 365 walk-through covers setup and your first chart.
Yes. The ProEssentials ActiveX/OCX interface was synchronized with the WPF and WinForms interfaces in v10.0.0.22, and the product installs a complete Access example database — C:\ProEssentials10\Access\PE10FullDemo.accdb — replicating all 116 examples, including the most intense Direct3D compute-shader demos, running inside Access. How many projects need GPU compute-shader charting in an Access database is an open question, but it is slightly crazy to watch, it works perfectly, and it is there if you need it. F1 context-sensitive help works inside the VBA editor, and the v10 AI Code Assistant's knowledge files cover the VBA workflow, so AI tools can write the Access-to-chart data-transfer code for you. The MS Access walk-through shows the setup end to end.
Both per-developer and corporate unlimited-developer licenses exist, and distribution is royalty-free in all cases. Every license is perpetual, includes every interface — WPF, WinForms, WebForms, ActiveX/OCX, DLL for C/C++/MFC, and VCL — and carries no runtime royalties, no per-machine activation, and no subscription requirement. Current pricing is on the price sheet; support is free, unlimited, and answered by the engineers who built the engine, so the license price is the whole price.
Yes, and it is fully functional — the evaluation is the complete product, not a reduced feature set. The download is instant with no account or registration, and interactive demos at the end of setup show the rendering quality and performance immediately. We encourage building your real data pipeline against the eval before purchasing; that firsthand result is worth more than any comparison page, including ours.
The full five-library rendering comparison: compute shaders, game loops, CPU paths, and what each means for your data.
Read morehDC coupling, why native WinForms beats WPF on the same engine, and the 100M-point methodology.
Read moreHow pe_query.py validates AI-generated chart code against the compiled DLL — no hallucinated APIs.
Read moreProEssentials support is free, unlimited, and answered directly by the engineers who built the rendering engine. No ticket limits, no subscription required. Ask us anything about WPF, WinForms, MFC, Delphi, or real-time performance.
Contact the ProEssentials Team →Your success is our #1 goal by providing the easiest and most professional benefit to your organization and end-users.
ProEssentials was born from professional Electrical Engineers needing their own charting components. Join our large list of top engineering companies using ProEssentials.
Thank you for being a ProEssentials customer, and thank you for researching the ProEssentials charting engine.