100 Millionen Punkte in WPF zeichnen

Wie zeigt man 100.000.000 Datenpunkte in einem WPF-Liniendiagramm an? Die Antwort hängt vollständig davon ab, welche Charting-Bibliothek Sie verwenden. Einige bewältigen es in 15 Zeilen Code ohne Speicher-Overhead. Einige benötigen spezialisierte Serientypen und opfern die Datentreue. Einige können es schlichtweg gar nicht.

Dieser Beitrag bietet vollständigen, funktionierenden C#-Code für alle fünf großen WPF-Charting-Bibliotheken — ProEssentials, SciChart, LightningChart, Syncfusion und DevExpress — die versuchen, dieselben 100 Millionen Float-Werte in ein Einzelserien-Liniendiagramm zu zeichnen. Wir vergleichen jeden Aspekt: Codezeilen, Speicherverbrauch, Renderzeit, Datentreue und was jede Bibliothek hinter den Kulissen tatsächlich mit Ihren Daten macht.

Wenn Sie nach "Millionen Punkte WPF zeichnen" oder "WPF Chart Performance" gesucht haben, ist dies die konkrete Antwort auf Code-Ebene.

Probieren Sie es selbst aus: Die Installation von ProEssentials enthält eine Demo namens GigaPrime2D (mit vollständigem Beispielprojekt-Quellcode). Diese Demo plottet kontinuierlich 100 Millionen Punkte — alle 100M Werte werden bei jeder Aktualisierung geändert. Der Code ist bewusst minimal gehalten, sodass es einfach ist, eine konkurrierende Bibliothek einzubinden und einen funktionierenden Seite-an-Seite-Vergleich mit 100 Millionen Punkten zu erstellen.

Der Test: 100.000.000 Float-Werte

Jede Bibliothek erhält denselben Test: Rendere ein Einzelserien-Liniendiagramm aus 100 Millionen sequentiellen Float-Werten, die eine Sinuswelle mit zufälligem Rauschen darstellen — ein typisches Muster für Sensordaten, Signalverarbeitung und wissenschaftliche Erfassung. Die Frage ist nicht, ob das Diagramm hübsch aussieht — sondern ob die Bibliothek die Daten überhaupt verarbeiten kann, und was es an Speicher, Zeit und Treue kostet.

Nachfolgend zeigen wir den vollständigen C#-Code für jede Bibliothek, annotiert mit dem, was bei jedem Schritt mit Ihren Daten passiert. Achten Sie auf zwei Dinge: wie die Bibliothek Ihre Daten empfängt (Kopie vs. Zeiger) und wie sie rendert (jeden Punkt vs. resampeltes Subset).

Bibliothek 1: ProEssentials — Zero-Copy + GPU Compute Shader

ProEssentials verwendet UseDataAtLocation(), um das Diagramm direkt auf Ihr vorhandenes Float-Array zu verweisen. Keine Kopie, keine Konvertierung, keine Duplikation. Die native DLL des Diagramms speichert einen Zeiger auf Ihren Speicher und liest ihn beim Rendering. In Kombination mit ComputeShader = true konstruiert der GPU-Compute-Shader das Diagrammbild mit potenziell über 2.000 Shader-Kernen — die CPU iteriert nie über die 100 Millionen Werte.

// ProEssentials — Plot 100 Million Points (WPF, ~15 lines)
// NuGet: Install-Package Gigasoft.ProEssentials

// 1. Allocate your data — this is the ONLY copy that will ever exist
float[] yData = new float[100_000_000];
for (int i = 0; i < yData.Length; i++)
    yData[i] = (float)Math.Sin(i * 0.0001) + (float)(rand.NextDouble() * 0.1);

// 2. Configure the chart
Pesgo1.PeData.Subsets = 1;
Pesgo1.PeData.Points = 100_000_000;
Pesgo1.PePlot.Method = SGraphPlottingMethod.Line;
Pesgo1.PeConfigure.RenderEngine = RenderEngine.Direct3D;
Pesgo1.PeData.ComputeShader = true;
Pesgo1.PeData.Filter2D3D = true;  // GPU pre-filter shader — lossless min/max

// 3. Zero-copy: point the chart at your existing array — no duplication
Pesgo1.PeData.Y.UseDataAtLocation(yData, yData.Length);

// 4. Tell the Direct3D engine to rebuild vertices and colors
Pesgo1.PeFunction.Force3dxVerticeRebuild = true;
Pesgo1.PeFunction.Force3dxNewColors = true;

// 5. Render
Pesgo1.PeFunction.ReinitializeResetImage();

Die Schlüsselzeile ist UseDataAtLocation(yData, yData.Length). Dies ist keine Kopieroperation — es ist eine Zeigerzuweisung. Das Diagramm liest Ihr Array vor Ort. Mit Filter2D3D = true fügt ProEssentials einen vorgeschalteten GPU-Compute-Shader in die Rendering-Pipeline ein, der verlustfreies Min/Max-Filtern durchführt, bevor der finale Rendering-Shader läuft. Im Gegensatz zum aggressiven Viewport-Breiten-Resampling von SciChart und DevExpress — das 100 Millionen Punkte auf wenige Tausend reduzieren kann — ist ProEssentials' Filter bewusst konservativ: Eine Serie behält nach dem Filtern stets mindestens 500.000 Punkte, da es keinen Grund gibt, mehr Daten zu verwerfen als nötig, wenn sowohl der Filter-Shader als auch der Rendering-Shader auf der GPU in Mikrosekunden ausgeführt werden. Das Ergebnis ist eine verlustfreie Darstellung, die jede Spitze, jedes Tal und jeden Transienten in Ihrem Signal bewahrt.

Die Flags Force3dxVerticeRebuild und Force3dxNewColors weisen die Direct3D-Engine an, ihre Vertex- und Farbdaten aus dem Quell-Array zu rekonstruieren. Wenn Sie später Werte in yData ändern und diese Flags erneut setzen, bevor Sie ReinitializeResetImage() aufrufen, spiegelt das Diagramm die Änderungen sofort wider, weil es denselben Speicher liest. Das gesamte Setup umfasst 15 Zeilen. Kein spezieller Serientyp — dasselbe Pesgo (Scientific Graph Object), das 100 Punkte verarbeitet, verarbeitet auch 100 Millionen. ProEssentials' eigenes Beispiel 115 zeichnet 20 Millionen Punkte über 5 Serien (insgesamt 100 Millionen) und rendert mit interaktiver Geschwindigkeit — 20 Millionen pro Serie sind schlichtweg nichts für die Compute-Shader-Pipeline.

Bibliothek 2: SciChart — Array-Kopie + Resampling

SciChart kann 100 Millionen Punkte anzeigen, aber der Weg beinhaltet zwei bedeutende Kompromisse. Erstens kopiert dataSeries.Append() alle 100 Millionen Werte in SciCharts internen Speicher als double[] — der Speicher wird von Float (4 Bytes) auf Double (8 Bytes) verdoppelt. Zweitens downsampled SciCharts Rendering-Pipeline die Daten auf etwa 2× die Viewport-Breite (ungefähr 3.840 Punkte auf einem 1920-Pixel-Display).

// SciChart — Plot 100 Million Points (WPF)
// NuGet: Install-Package SciChart, SciChart.Wpf

// 1. Allocate your data
double[] yData = new double[100_000_000];  // Note: SciChart uses double[], not float[]
double[] xData = new double[100_000_000];
for (int i = 0; i < yData.Length; i++) {
    xData[i] = i;
    yData[i] = Math.Sin(i * 0.0001) + rand.NextDouble() * 0.1;
}

// 2. Create data series — copies all 100M values into internal storage
var dataSeries = new XyDataSeries<double, double>();
dataSeries.Append(xData, yData);  // ~800 MB internal copy (float→double + overhead)

// 3. Configure resampling — without this, 100M points will not render
var lineSeries = new FastLineRenderableSeries();
lineSeries.DataSeries = dataSeries;
lineSeries.ResamplingMode = ResamplingMode.Auto;  // downsamples to ~2×viewport width

// 4. Add to chart surface
sciChartSurface.RenderableSeries.Add(lineSeries);

Die Einstellung ResamplingMode.Auto macht 100M Punkte in SciChart überhaupt machbar. Ohne sie müsste die GPU-Pipeline Vertex-Buffer für 100 Millionen Datenpunkte verarbeiten — so funktioniert SciCharts Game-Engine-Architektur nicht. Stattdessen wählt der CPU-seitige Resampler ein repräsentatives Subset (mittels Min/Max pro Pixel-Bin), und nur dieses Subset wird zur GPU zum Rendering gesendet.

Das bedeutet, SciChart rendert ungefähr 3.840 Punkte von 100 Millionen — etwa 0,004 % Ihrer Daten. Für die visuelle Übersicht bei vollem Herauszoomen ist dies oft akzeptabel. Wenn Sie jedoch in ein 1-Sekunden-Fenster einer 10-Stunden-Aufzeichnung zoomen, scannt der Resampler den relevanten Bereich auf der CPU erneut, um ein neues repräsentatives Subset zu erzeugen. Die ursprünglichen 100 Millionen Werte liegen in SciCharts internem double[]-Array und verbrauchen ~800 MB, wartend darauf, bei Bedarf resampelt zu werden.

Bibliothek 3: LightningChart — Array-Kopie + Spezialisierter Serientyp

LightningChart kann 100 Millionen Punkte verarbeiten, aber nur über seine SampleDataSeries — einen spezialisierten Serientyp, der speziell für gleichmäßig abgetastete Daten mit festem Intervall konzipiert ist. Standard-Serientypen (PointLineSeries, FreeformPointLineSeries) können diese Skala nicht bewältigen. Die Daten werden über die Methode AddSamples(float[]) in einen internen Buffer kopiert, den LightningCharts DirectX-Immediate-Mode-Renderer dann verarbeitet. Eine neuere Variante, SampleDataBlockSeries (v10.1+), bietet noch bessere Leistung für Streaming-/Sweep-Szenarien.

// LightningChart — Plot 100 Million Points (WPF)
// NuGet: Install-Package Arction.LightningChart.Ultimate

// 1. Allocate your data
float[] yData = new float[100_000_000];
for (int i = 0; i < yData.Length; i++)
    yData[i] = (float)Math.Sin(i * 0.0001) + (float)(rand.NextDouble() * 0.1);

// 2. Configure chart for large data — must use Non-Bindable edition for best performance
lightningChart.BeginUpdate();
lightningChart.ViewXY.XAxes[0].SetRange(0, 100_000_000);

// 3. Create SampleDataSeries (fixed-interval data) — standard PointLineSeries can't scale
var series = new SampleDataSeries(lightningChart.ViewXY, lightningChart.ViewXY.XAxes[0],
    lightningChart.ViewXY.YAxes[0]);
series.FirstSampleTimeStamp = 0;
series.SamplingFrequency = 1;  // 1 sample per X unit (sequential)

// 4. Add all 100M samples — copies float[] into internal buffer
series.AddSamples(yData, false);

// 5. Add series to chart
lightningChart.ViewXY.SampleDataSeries.Add(series);
lightningChart.EndUpdate();

// Note: SampleDataBlockSeries (v10.1+) is the newer, faster alternative
//       for streaming/sweeping data. Both require Non-Bindable edition
//       for best performance — MVVM data binding is limited.

Die kritische Einschränkung: Für beste Leistung erfordert LightningChart die Non-Bindable-Edition. LightningCharts WPF-Produkt wird in Bindable- und Non-Bindable-Editionen geliefert — die Non-Bindable-Edition ist schneller und unterstützt Multithreading, opfert aber WPFs MVVM-Datenbindungsinfrastruktur. Wenn Ihre Anwendung WPFs Datenbindungsmuster verwendet (wie die meisten modernen WPF-Apps), stehen Sie vor einem Kompromiss zwischen Leistung und architektonischer Kompatibilität.

LightningChart rendert alle 100 Millionen Punkte (verlustfrei) durch seine DirectX-Pipeline. Der Kompromiss ist die Array-Kopie (~400 MB zusätzlicher Speicher), der obligatorische spezialisierte Serientyp, die Non-Bindable-Edition-Empfehlung und LightningCharts kontinuierliche Rendering-Schleife, die die GPU auch bei untätigem Diagramm aktiv hält.

Bibliothek 4: Syncfusion — Objekt-pro-Punkt-Architektur

Syncfusions WPF-Charting verwendet ein Objekt-pro-Punkt-Datenmodell. Jeder Datenwert muss in eine Klasseninstanz (typischerweise mit X- und Y-Eigenschaften) eingewickelt und einer IEnumerable-Sammlung hinzugefügt werden. Bei 100 Millionen Punkten bedeutet das die Erstellung von 100 Millionen .NET-Objekten — jedes mit einem 24-Byte-Objekt-Header (auf 64-Bit), zwei Double-Eigenschaften (16 Bytes) und Padding. Gesamt: ungefähr 2,4 GB verwaltete Heap-Allokationen zusätzlich zu den ursprünglichen 400 MB Quelldaten.

// Syncfusion — Plot 100 Million Points (WPF)
// NuGet: Install-Package Syncfusion.SfChart.WPF

// 1. Create data model class — Syncfusion requires object-per-point
public class DataPoint {
    public double X { get; set; }
    public double Y { get; set; }
}

// 2. Allocate 100 million objects (~2.4 GB+ with object headers)
var data = new ObservableCollection<DataPoint>();
for (int i = 0; i < 100_000_000; i++)
    data.Add(new DataPoint {
        X = i,
        Y = Math.Sin(i * 0.0001) + rand.NextDouble() * 0.1
    });
// ⚠ This loop alone takes minutes and will likely trigger OutOfMemoryException
//    Syncfusion's practical ceiling is ~1 million points

// 3. Use FastLineBitmapSeries for best performance
var series = new FastLineBitmapSeries();
series.ItemsSource = data;
series.XBindingPath = "X";
series.YBindingPath = "Y";
chart.Series.Add(series);

In der Praxis dauert diese Allokationsschleife Minuten und löst typischerweise eine OutOfMemoryException aus, bevor sie abgeschlossen ist, besonders bei 32-Bit-Prozessen oder Systemen mit begrenztem Speicher. Syncfusions praktische Obergrenze für reaktionsfähiges Charting liegt bei ungefähr 1 Million Punkten mit FastLineBitmapSeries. Die Bibliothek ist gut geeignet für Business-Dashboards mit moderaten Datenvolumen, aber nicht für das 100-Millionen-Punkte-Szenario in Wissenschaft und Technik konzipiert.

Bibliothek 5: DevExpress — Objekt-pro-Punkt + Resampling

DevExpress WPF verwendet eine LineSeries2D mit AllowResample = true für große Daten. Hinweis: DevExpress' SwiftPlotSeriesView, oft in Leistungsdiskussionen referenziert, ist WinForms-only und existiert nicht im WPF-Chart-Control. In WPF ermöglicht AllowResample (eingeführt in v20.1) Viewport-abhängiges Resampling, das das Rendering auf den sichtbaren Bereich begrenzt. DevExpress' eigener Blogbeitrag testete diesen Ansatz mit bis zu 50 Millionen Punkten. Das Datenmodell ist jedoch weiterhin Objekt-pro-Punkt — bei 100 Millionen müssen ~2,4 GB DataPoint-Objekte allokiert werden, bevor das Rendering beginnen kann.

// DevExpress — Plot 100 Million Points (WPF)
// NuGet: Install-Package DevExpress.Wpf.Charts

// 1. Create data model — DevExpress WPF requires object-per-point
public class DataPoint {
    public double Argument { get; set; }
    public double Value { get; set; }
}

// 2. Allocate 100 million objects (~2.4 GB+ with object headers)
var data = new List<DataPoint>(100_000_000);
for (int i = 0; i < 100_000_000; i++)
    data.Add(new DataPoint {
        Argument = i,
        Value = Math.Sin(i * 0.0001) + rand.NextDouble() * 0.1
    });
// ⚠ Minutes of allocation, ~2.4 GB managed heap
//    DevExpress tested AllowResample up to 50M (v20.1 blog post)

// 3. Use LineSeries2D with AllowResample (resamples to viewport)
var series = new LineSeries2D();
series.DataSource = data;
series.ArgumentDataMember = "Argument";
series.ValueDataMember = "Value";
series.AllowResample = true;   // critical — resamples to viewport width
series.MarkerVisible = false;  // required for large-data performance
series.LineStyle.Thickness = 1;

// 4. Add to XYDiagram2D
var diagram = (XYDiagram2D)chartControl.Diagram;
diagram.Series.Add(series);

// Note: SwiftPlotSeriesView is WinForms-only — NOT available in WPF.
//       WPF uses LineSeries2D + AllowResample for large data.

Bei 100 Millionen Punkten ist die Erstellung von 100 Millionen .NET-Objekten auf einem 64-Bit-System mit ausreichend RAM (~2,8 GB gesamt inklusive Quelldaten) grenzwertig machbar. Wenn die Allokation gelingt, rendert AllowResample nur das Viewport-Subset — ähnlich SciCharts Resampling-Ansatz. Anders als SciChart (das rohe Doubles in einem flachen Array speichert) speichert DevExpress jedoch verpackte Objekte mit 24-Byte-Headern, wodurch die Speicherkosten pro Punkt etwa 6× höher sind. DevExpress' getestete Obergrenze ist 50 Millionen; 100 Millionen sind nach ihren veröffentlichten Benchmarks ungetestetes Territorium.

Was Resampling Sie kostet

SciChart und DevExpress verwenden beide Resampling als praktischen Engineering-Kompromiss: Ein repräsentatives Subset der Daten anzeigen statt alles zu rendern. Auf einem 1920 Pixel breiten Diagramm gibt es maximal 1.920 horizontale Pixelspalten. 100 Millionen Punkte in 1.920 Spalten zu rendern bedeutet, dass ~52.083 Punkte um jedes Pixel konkurrieren. SciCharts Resampler wählt den Min- und Max-Wert pro Bin und produziert etwa 3.840 repräsentative Punkte — genug, um die visuelle Hülle der Daten zu bewahren. DevExpress' AllowResample verwendet einen ähnlichen Viewport-limitierten Ansatz.

Für Übersichtsanzeigen ("Zeig mir den gesamten Datensatz") ist dies oft visuell nicht von verlustfreiem Rendering zu unterscheiden. Das Problem tritt auf, wenn Präzision wichtig ist: Anomalieerkennung in wissenschaftlichen Daten, exakte Spitzenidentifikation in der Signalverarbeitung oder regulatorische Compliance in medizinischer/pharmazeutischer Aufzeichnung, wo jedes Sample verifizierbar sein muss. Wenn ein 1-Sample-Transient an Punkt 47.291.033 aufgetreten ist, kann ein Resampler, der 52.083 Punkte auf 2 Repräsentanten pro Pixelspalte reduziert, diesen spezifischen Punkt möglicherweise auswählen oder auch nicht.

ProEssentials verfolgt einen fundamental anderen Ansatz mit seinem Filter2D3D-GPU-Compute-Shader. Anstatt 100 Millionen Punkte aggressiv auf eine Handvoll bildschirmbreiter Repräsentanten zu reduzieren, führt der Filter2D3D-Shader einen konservativen, verlustfreien Min/Max-Vorfilter-Durchgang auf der GPU durch — und das Ergebnis behält stets mindestens 500.000 Punkte. Die Logik ist einfach: Wenn sowohl der Filter-Shader als auch der finale Rendering-Shader auf der GPU in Mikrosekunden ausgeführt werden, gibt es keinen Grund, aggressiv Daten zu verwerfen. Der Filter bewahrt jedes Min und Max innerhalb jedes Filterfensters, sodass Transienten, Spitzen und Anomalien nie verworfen werden. Er ist fundamental verlustfrei — das gerenderte Bild ist identisch mit einem aus dem vollständigen Datensatz erzeugten. LightningChart rendert ebenfalls verlustfrei durch seine DirectX-Pipeline, erfordert aber eine Array-Kopie (~400 MB Overhead) und eine kontinuierliche Rendering-Schleife. ProEssentials erreicht dasselbe verlustfreie Ergebnis mit null Speicher-Overhead und On-Demand-Rendering.

Was es kostet, 100 Millionen Punkte zu zeichnen

Vier Bibliotheken können versuchen, 100 Millionen Punkte zu rendern, obwohl nur drei bei dieser Skala getestet wurden. Hier sind die Kosten für jede — einschließlich des Lizenzmodells, denn eine Bibliothek, die 100M Punkte verarbeiten kann, aber über 5 Jahre $288.750 kostet, ist ein anderes Angebot als eine, die einmalig $11.999 kostet:

ProEssentials ist die einzige Bibliothek, die Zero-Copy-Datenladen, verlustfreies GPU-Compute-Shader-Filtern, On-Demand-Frame-Modell, dauerhafte Lizenzierung und kostenlosen unbegrenzten Support kombiniert — zu einem Bruchteil der Abonnementkosten der anderen Bibliotheken, die den Datensatz verarbeiten können.

Das Fazit

Vier Bibliotheken können 100 Millionen Punkte in WPF versuchen. Nur ProEssentials tut es mit null Speicher-Overhead, verlustfreiem GPU-Filtern und On-Demand-Rendering — in 15 Zeilen Code. SciChart bewältigt die Skala durch Resampling (schnell, aber verlustbehaftet). LightningChart bewältigt es durch einen spezialisierten Serientyp (verlustfrei, aber erfordert Array-Kopie, Non-Bindable-Edition, kontinuierliche GPU). DevExpress kann es mit AllowResample versuchen (Resampling, aber mit 2,4 GB Objekt-Overhead — in eigenen Benchmarks nicht über 50M getestet).

Syncfusion ist nicht für dieses Szenario konzipiert. Seine Objekt-pro-Punkt-Architektur erreicht Speichergrenzen weit unter 100 Millionen, mit dokumentierten Out-of-Memory-Abstürzen in eigenen Foren bei 16 Millionen Punkten. DevExpress hat denselben Objekt-pro-Punkt-Engpass, mildert ihn aber teilweise mit Viewport-Resampling — wenn die anfängliche Allokation gelingt. Beide Bibliotheken brillieren bei Business-Dashboards mit Datensätzen unter 1 Million Punkten, wo ihre breiten UI-Steuerelemente-Suiten Wert bieten, den dedizierte Charting-Bibliotheken nicht haben.

Wenn Ihre Anwendung 100 Millionen Punkte anzeigen muss — Sensordaten, Signalverarbeitung, wissenschaftliche Erfassung, industrielle Überwachung — zeigt der obige Code genau, was jede Bibliothek erfordert. Kopieren Sie ihn, führen Sie ihn aus, messen Sie. Die Zahlen sprechen für sich.

GPU-Architektur Deep Dive

Wie Compute Shaders, On-Demand-Rendering und Zero-Copy-Datenladen unter der Haube funktionieren.

KI-Code-Unterstützung

pe_query.py validiert jeden Eigenschaftspfad gegen die kompilierte DLL-Binärdatei — keine halluzinierten API-Aufrufe.

Preise & Support Vergleich

5-Jahres-TCO für 10 Entwickler über alle fünf Bibliotheken. Dauerhaft vs. Abonnement-Lizenzierung.

Quellen & Referenzen

Alle Konkurrenz-Codebeispiele in diesem Beitrag wurden aus offizieller Dokumentation, öffentlichen GitHub-Repositories und Hersteller-Forenbeiträgen erstellt. API-Namen, Methodensignaturen und Architekturaussagen wurden anhand der unten aufgeführten Quellen verifiziert. Links aktuell Stand Februar 2026.