WPF-Diagramm GPU-Leistung:
5-Bibliotheken Architekturvergleich
WPF-Diagramm GPU-Leistung:
Compute Shaders vs Game-Engine-Schleifen vs CPU-Rendering
Die Rendering-Engine ist die folgenreichste architektonische Entscheidung in einer Charting-Bibliothek. Sie bestimmt, wie viele Punkte Sie zeichnen können, ob Sie alle sehen oder eine resampelte Annäherung, wie viel Speicher das Diagramm verbraucht, wie viel Strom es zieht, und ob Ihr Laptop-Lüfter anspringt, sobald Sie ein Dashboard öffnen. Dennoch reduzieren die meisten Vergleichsseiten dies auf ein einzelnes Häkchen: 'GPU-beschleunigt — ja / nein.' Das reicht bei Weitem nicht für eine fundierte technische Entscheidung.
Diese Seite erklärt die vier unterschiedlichen Rendering-Architekturen, die von den fünf gängigsten WPF-Charting-Bibliotheken verwendet werden, mit spezifischen technischen Details darüber, wie jede funktioniert, welche Kompromisse sie eingeht und was diese Kompromisse für reale Anwendungen bedeuten.
Kurzreferenz: Rendering-Architektur im Vergleich
| Architecture | ProEssentials | SciChart | LightningChart | Syncfusion | DevExpress |
|---|---|---|---|---|---|
| GPU technology | Direct3D Compute Shaders | DirectX game-engine pipeline | DirectX immediate-mode | None — CPU only | None (optional DirectX bolt-on) |
| Where chart is built | GPU — compute shader constructs image | GPU — vertex buffer pipeline | GPU — DirectX draw calls | CPU — iterates pixels on CPU | CPU — GDI+ / optional DirectX |
| Frame model | On-demand — renders only when data changes | Continuous — 60 fps game loop always running | Continuous — DirectX render loop always running | On-demand — renders on invalidation | On-demand — renders on invalidation |
| GPU activity when idle | Zero | Full — redraws every 16 ms | Full — continuous refresh | Zero | Zero |
| Data fidelity | Lossless — every point rendered | Resampled — downsampled to viewport width | Lossless | Lossless | Resampled (AllowResample CTP) |
| Data loading | Zero-copy — reads your array in place | Copies into internal DataSeries | Copies via AddSamples | IEnumerable object iteration | SeriesPoint object collection |
| 100 M point render time | ~15 ms | ~ms (renders resampled subset) | ~ms (SampleDataSeries) | Not feasible (OOM at ~16 M) | ~ms (resampled, borderline at 100 M) |
| 100 M point memory overhead | ~0 MB | ~800 MB (duplicates as double[]) | Varies (block allocation) | ~2.4 GB+ (object headers) | ~2.4 GB+ (object headers) |
Vier Rendering-Architekturen im Detail
Jede WPF-Charting-Bibliothek auf dem Markt fällt in eine von vier Architekturkategorien. Das Verständnis dieser Kategorien ist wichtiger als das Lesen von Benchmark-Zahlen, denn die Architektur bestimmt die Obergrenze dessen, was die Bibliothek jemals leisten kann — keine noch so große Optimierung kann eine grundlegend limitierende Architektur überwinden.
ProEssentials: Direct3D Compute Shaders
ProEssentials verwendet Direct3D Compute Shaders — dieselbe GPU-Technologie, die in wissenschaftlichen Simulationen, Machine-Learning-Inferenz und Physik-Engines verwendet wird — um das Diagrammbild vollständig auf der GPU zu konstruieren. Dies unterscheidet sich architektonisch grundlegend von der Nutzung der GPU lediglich zum Zeichnen von Dreiecken (der Game-Engine-Ansatz).
In einer Compute-Shader-Architektur sendet die CPU Ihr Rohdaten-Array einmal an den GPU-Speicher. Die GPU führt dann ein Shader-Programm aus, das jeden Datenpunkt parallel verarbeitet — Tausende von GPU-Kernen bearbeiten jeweils einen Teil des Datensatzes gleichzeitig. Der Shader bestimmt die Pixelposition, Farbe und Sichtbarkeit jedes Punktes, schreibt das Ergebnis direkt in eine GPU-Textur, und das fertige Bild wird auf dem Bildschirm angezeigt.
Der entscheidende Vorteil ist, dass die CPU nie über Ihre Daten iteriert. Es gibt keine verwaltete Schleife, die 100 Millionen Floats durchläuft. Es gibt keine Konvertierung von Float zu Double. Es gibt keine Allokation von Zwischenobjekten. Die GPU erledigt die gesamte Arbeit, und zwar massiv parallel — eine moderne GPU hat 2.000–10.000 Kerne, die alle gleichzeitig arbeiten.
Ebenso wichtig: ProEssentials führt diese Pipeline nur aus, wenn sich Daten tatsächlich ändern. Wenn das Diagramm untätig auf dem Bildschirm steht — was die meiste Zeit seiner Lebensdauer in einem Dashboard oder Bericht ist — leistet die GPU exakt null Arbeit. Dieses On-Demand-Modell bedeutet, dass ProEssentials GPU-Geschwindigkeit liefert, wenn Sie sie brauchen, und null Stromverbrauch, wenn nicht.
Compute Shaders verarbeiten Daten parallel auf der GPU. On-Demand-Rendering bedeutet null GPU-Kosten im Leerlauf. Diese Kombination — GPU-Geschwindigkeit mit On-Demand-Sparsamkeit — ist unter WPF-Charting-Bibliotheken einzigartig bei ProEssentials.
SciChart: GPU Game-Engine-Rendering-Schleife
SciChart verwendet eine Game-Engine-ähnliche Rendering-Pipeline. Die Bibliothek unterhält eine kontinuierliche Rendering-Schleife, die etwa 60 Mal pro Sekunde (alle ~16 Millisekunden) auslöst und das Diagramm bei jedem Frame neu zeichnet, unabhängig davon, ob sich etwas geändert hat.
Diese Architektur stammt aus der Welt der Spiele und Trading-Terminals, wo angenommen wird, dass sich der Bildschirminhalt ständig ändert und flüssige Animation oberste Priorität hat. SciChart konvertiert Ihre Daten in GPU-Vertex-Buffer und rendert sie durch eine traditionelle Grafik-Pipeline — Vertex-Shader, Rasterizer, Pixel-Shader — dieselbe Pipeline, die 3D-Spielszenen zeichnet.
Die Stärke dieses Ansatzes ist die Animationsflüssigkeit. Da die Schleife immer läuft, erscheint jede Änderung an Daten oder Ansichtsfenster im nächsten Frame, typischerweise innerhalb von 16 Millisekunden. Für Anwendungen wie Finanz-Trading-Terminals, wo Kerzen, Ticks und Orderbuch-Tiefen ständig aktualisiert werden, stellt diese kontinuierliche Schleife sicher, dass nichts veraltet ist.
Die kontinuierliche Schleife hat jedoch einen Preis. SciChart zeichnet das vollständige Diagramm 60 Mal pro Sekunde neu, auch wenn sich Ihre Daten nicht geändert haben. Ein Dashboard mit acht SciChart-Oberflächen im Leerlauf erzeugt immer noch 480 Frames pro Sekunde identischer Ausgabe. Die GPU bleibt aktiv, der Lüfter kann anspringen, und der Stromverbrauch ist konstant. SciChart bietet einen Mechanismus zum Deaktivieren der Rendering-Schleife, aber dies ist nicht das Standardverhalten, und viele Entwickler entdecken es nie.
Um 60 fps bei großen Datensätzen aufrechtzuerhalten, resampelt SciChart Ihre Daten auf etwa 2× die Viewport-Pixelbreite herunter. Bei 1920 Pixeln Breite wird ein 100-Millionen-Punkte-Datensatz auf ~3.840 repräsentative Punkte zum Rendering reduziert. Die vollständigen Daten bleiben im Speicher, aber 99,996 % davon werden in keinem einzelnen Frame gezeichnet. Das bedeutet, dass Anomalien, schmale Spitzen und feine Details zwischen den gesampelten Punkten unsichtbar sind, bis Sie hineinzoomen.
LightningChart: DirectX Immediate-Mode
LightningChart verwendet DirectX auf relativ niedriger Ebene und gibt Draw-Calls über die DirectX-API aus, um Diagramminhalte zu rendern. Wie SciChart unterhält es eine kontinuierliche Rendering-Schleife, was bedeutet, dass die GPU aktiv ist, auch wenn sich die Diagrammdaten nicht geändert haben.
LightningChart kann Daten verlustfrei rendern — es resampelt standardmäßig nicht — was ein erheblicher Vorteil gegenüber SciChart für wissenschaftliche Anwendungen ist, bei denen jeder Datenpunkt sichtbar sein muss. Um dies jedoch bei 100-Millionen-Punkte-Skala zu erreichen, muss der SampleDataSeries-Typ (oder der neuere SampleDataBlockSeries) mit der Non-Bindable-Diagrammvariante verwendet werden, was WPF-Datenbindung und MVVM-Kompatibilität aufgibt.
Die kontinuierliche Rendering-Schleife bedeutet, dass LightningChart die Stromverbrauchseigenschaften von SciChart teilt: GPU bleibt im Leerlauf aktiv, der Lüfter kann bei Laptops anspringen, und eingebettete oder batteriebetriebene Deployments akkumulieren unnötige thermische und Energiekosten. LightningChart bietet keine einfache Eigenschaft zum Umschalten auf On-Demand-Rendering.
Syncfusion und DevExpress: CPU-Standard-Rendering
Syncfusion und DevExpress verwenden beide standardmäßig CPU-basiertes Rendering. Syncfusion nutzt WPFs WriteableBitmap — eine verwaltete Bitmap, die die CPU Pixel für Pixel füllt. DevExpress verwendet eine Kombination aus WPFs eingebautem Rendering und GDI+, mit einem optionalen DirectX-Modus und einer Resampling-Eigenschaft (AllowResample), die die getestete Obergrenze auf etwa 50 Millionen Punkte erweitert.
CPU-Rendering ist für die Zeichenphase inhärent single-threaded. Während beide Bibliotheken Daten auf Hintergrund-Threads vorbereiten können, erfolgt das eigentliche Pixel-Schreiben auf dem UI-Thread. Dies erzeugt eine harte Obergrenze: Das Diagramm kann nur so viele Punkte verarbeiten, wie ein einzelner CPU-Kern innerhalb einer angemessenen Frame-Zeit durchlaufen kann. In der Praxis liegt diese Obergrenze bei etwa 500.000 bis 1.000.000 Punkten, bevor die Benutzeroberfläche zu ruckeln beginnt.
Der Vorteil von CPU-Rendering ist Einfachheit und Kompatibilität. Es gibt keine GPU-Treiber-Anforderungen, keine DirectX-Abhängigkeiten und kein VC++ Redistributable zu deployen. Für Anwendungen mit weniger als 100.000 Punkten — was die meisten Business-Dashboards, HR-Analysen und Projektmanagement-Tools einschließt — ist CPU-Rendering vollkommen ausreichend, und die breite UI-Suite, die diese Anbieter bieten, bietet echten Mehrwert.
On-Demand vs Kontinuierliches Rendering: Was Ihr Dashboard tatsächlich tut
Der Unterschied zwischen On-Demand- und kontinuierlichem Rendering ist der am meisten unterschätzte Faktor bei der Auswahl einer Charting-Bibliothek. Er hat null Einfluss auf Benchmark-Screenshots, aber enormen Einfluss auf reale Deployments — besonders Laptops, eingebettete Systeme, Multi-Monitor-Setups und jede Anwendung, bei der Diagramme Bildschirmplatz mit anderen Steuerelementen teilen.
| Scenario | On-Demand (ProEssentials) | Continuous 60 fps (SciChart / LightningChart) |
|---|---|---|
| Dashboard with 8 charts, no data flowing | 0 frames / sec, ~0 % GPU | 480 frames / sec total (8 × 60), continuous GPU load |
| Real-time monitor, 10 updates / sec | 10 frames / sec, GPU active only during render | 60 frames / sec, 50 frames wasted redrawing identical content |
| Static report opened, user reading | 0 frames after initial paint | 60 frames / sec indefinitely — wasting power while user reads |
| Laptop on battery, multiple charts | Negligible battery draw from charting | Measurable battery drain — GPU never sleeps |
| Embedded kiosk, 24/7 operation | Low heat, low power, long hardware life | Continuous GPU heat, higher power bill, shorter GPU life |
| Smooth zoom / pan interaction | Renders every frame during interaction, stops when idle | Smooth — but was already rendering 60 fps before you touched it |
On-Demand-Rendering ist nicht langsamer als kontinuierliches Rendering. ProEssentials erreicht während des aktiven Renderings dieselbe GPU-beschleunigte Geschwindigkeit wie SciChart und LightningChart — die Compute-Shader-Pipeline ist genauso schnell. Der Unterschied liegt darin, was zwischen den Renderings passiert. ProEssentials tut nichts. SciChart und LightningChart zeichnen weiterhin identischen Inhalt 60 Mal pro Sekunde neu.
Datentreue: Sehen Sie jeden Punkt oder eine Annäherung?
Wenn eine Bibliothek behauptet, 100 Millionen Datenpunkte zu 'unterstützen', ist die entscheidende Folgefrage: Rendert sie tatsächlich alle 100 Millionen, oder resampelt sie diese auf wenige Tausend herunter und zeigt Ihnen eine Annäherung? Für Business-Dashboards ist Resampling akzeptabel — die visuelle Form der Daten bleibt erhalten. Für wissenschaftliche, medizinische und technische Anwendungen kann Resampling genau die Anomalie oder Spitze verbergen, die Sie finden müssen.
SciChart verwendet automatisches Resampling als Kernstrategie für große Datensätze. Wenn ResamplingMode auf Auto gesetzt ist (der Standard für große Daten), berechnet die Bibliothek etwa 2 Punkte pro horizontalem Pixel und rendert nur diese repräsentativen Punkte. Bei 1920 Pixeln Breite rendert ein 100-Millionen-Punkte-Liniendiagramm etwa 3.840 Punkte. Die Form sieht auf der Übersichts-Zoomstufe korrekt aus, aber feinkörnige Details zwischen diesen 3.840 Samples sind unsichtbar.
ProEssentials rendert jeden Datenpunkt. Der Compute Shader verarbeitet alle 100 Millionen Werte und bestimmt den korrekten Pixelbeitrag jedes einzelnen. Wenn drei Punkte auf dieselbe Pixelspalte abgebildet werden, berechnet der Shader korrekt die Min-, Max- und Close-Werte für diese Spalte — und bewahrt die visuelle Hülle der Daten einschließlich Spitzen und Anomalien, die Resampling übersehen würde.
LightningChart rendert ebenfalls verlustfrei, wenn der richtige Serientyp verwendet wird (SampleDataSeries mit Non-Bindable-Diagramm). Die Wahl des falschen Serientyps oder der Bindable-Diagrammvariante führt jedoch zu dramatisch schlechterer Leistung — um Größenordnungen langsamer — ohne Kompilierungswarnung, dass Sie den langsamen Pfad gewählt haben.
| Library | 100 M pts at 1920 px | Data Rendered |
|---|---|---|
| ProEssentials | All 100,000,000 | 100 % |
| SciChart | ~3,840 representative | 0.004 % |
| LightningChart | All (SampleDataSeries) | 100 % |
| Syncfusion | Not feasible | — |
| DevExpress | Resampled subset | Varies |
Warum das wichtig ist: In einer medizinischen EKG-Spur könnte eine einzelne Spitze auf eine Arrhythmie hinweisen. In der Schwingungsanalyse könnte ein schmaler Resonanzpeak nur wenige Samples umfassen. In der Halbleiterprüfung könnte eine kurze Abweichung nur Mikrosekunden dauern. Resampling verbirgt all dies. Verlustfreies Rendering zeigt es.
Zero-Copy-Datenladen: Warum sich der Speicher verdoppelt (oder nicht)
Jede Charting-Bibliothek benötigt Zugriff auf Ihre Daten. Die Frage ist, ob sie Ihr vorhandenes Array liest oder alles in ihren eigenen internen Speicher kopiert. Dieser Unterschied bestimmt Speicherverbrauch, Ladezeit und Garbage-Collection-Druck — drei Faktoren, die sich bei großer Skala dramatisch verstärken.
ProEssentials' UseDataAtLocation() speichert einen Zeiger auf Ihr vorhandenes Array. Das Diagramm allokiert nie seine eigene Kopie. Das bedeutet, dass das Laden von 100 Millionen Float-Werten effektiv null Zeit (eine Zeigerzuweisung) und null zusätzlichen Speicher benötigt. Sie ändern Ihr Quell-Array, rufen ReinitializeResetImage() auf, und das Diagramm rendert sofort aus den aktualisierten Daten.
| Factor | ProEssentials Zero-Copy | SciChart Append | LightningChart SampleDataSeries | Syncfusion / DevExpress |
|---|---|---|---|---|
| API call | UseDataAtLocation(array, count) | dataSeries.Append(yValues) | series.AddSamples(array, 0, count) | ItemsSource = collection |
| What happens to your data | Chart stores a pointer — reads your array directly | Entire array copied into internal storage | Copied into series buffer | Each value wrapped in object |
| Memory (100 M float values) | 400 MB (your array only) | 1,200 MB (400 MB source + 800 MB double copy) | 400 MB + block overhead | 2,800 MB+ (400 MB + 2.4 GB objects) |
| Time to load 100 M points | Instant — no copy, just a pointer assignment | Seconds — iterates and copies every value | Sub-second — array copy | Minutes or OOM crash |
| Update workflow | Modify your array → call Reinitialize | Clear + re-Append, or use FIFO with capacity | AddSamples with new data | Reset ItemsSource binding |
| GC pressure | Zero — no managed allocations | Moderate — internal array resizing | Low — array-based | Severe — millions of objects |
Für ein 100-Millionen-Punkte float[]-Array (400 MB) beträgt der gesamte Speicherbedarf: ProEssentials: 400 MB (nur Ihr Array). SciChart: 1.200 MB (Ihr Array + 800 MB interne double[]-Kopie). Syncfusion: 2.800 MB+ (Ihr Array + 2,4 GB pro-Punkt-Objekt-Wrapper). Bei 100 Millionen Punkten ist Zero-Copy keine Optimierung — es ist der Unterschied zwischen einer Anwendung, die läuft, und einer, die mit OutOfMemoryException abstürzt.
Echtzeit-Streaming-Leistung
Echtzeit-Charting fügt eine Dimension hinzu, die statische Benchmarks übersehen: Dauerhafter Durchsatz über die Zeit ohne Speicherwachstum. Eine Anwendung, die 10.000 Samples pro Sekunde über 8 Stunden streamt, erzeugt 288 Millionen Datenpunkte. Das Diagramm muss neue Daten anfügen, alte Daten verwerfen und Updates rendern — ohne Speicherlecks oder akkumulierten GC-Druck.
ProEssentials bietet eingebaute Ringpuffer (PeData.CircularBuffers = true setzen), die das rollende Fenster nativ handhaben. Neue Daten werden über AppendYData() angefügt, alte Daten fallen am hinteren Ende weg, und der Puffer wächst nie. In Kombination mit PrepareImages (das mehrere Anfügungen in ein einzelnes Rendering bündelt) entsteht eine effiziente Pipeline: Daten auf jedem Thread sammeln, bündeln, einmal rendern.
SciChart bietet FIFO-Modus (First-In-First-Out) auf seiner DataSeries, der ähnliches rollendes Verhalten erreicht. Der Unterschied ist, dass SciCharts kontinuierliche Rendering-Schleife das Diagramm 60 Mal pro Sekunde neu zeichnet, unabhängig von Ihrer Datenrate. Wenn Ihr Instrument 10 Updates pro Sekunde produziert, rendert SciChart 50 redundante Frames zwischen jedem Update. ProEssentials rendert exakt 10 Frames — einen pro Datenupdate — und die GPU ist die restliche Zeit untätig.
| Real-Time Factor | ProEssentials | SciChart |
|---|---|---|
| Circular buffer | Built-in property | FIFO capacity on DataSeries |
| Append new data | AppendYData / AppendYDataII | dataSeries.Append() |
| PrepareImages (batch) | ✅ Suppresses render until ready | SuspendUpdates / ResumeUpdates |
| Thread safety | Native C — no STA requirement | Must dispatch to UI thread |
| Idle between updates | Zero GPU activity | Still rendering 60 fps |
Welche Architektur passt zu Ihrer Anwendung?
Keine einzelne Architektur ist für jedes Szenario die beste. Hier ist eine klare Anleitung basierend darauf, was Ihre Anwendung tatsächlich benötigt:
| Your Application | Best Architecture | Why |
|---|---|---|
| Scientific / engineering with large datasets | ProEssentials — GPU compute + zero-copy | Lossless rendering of 100 M+ points, no memory duplication, on-demand frames |
| Real-time monitoring dashboard | ProEssentials — on-demand + circular buffers | Renders only on new data, native circular buffer, zero idle GPU cost |
| Trading terminal (60 fps animation needed) | SciChart — continuous game loop | Continuous animation suits constantly updating financial tickers |
| Medical device, battery or embedded | ProEssentials — low power on-demand | Zero GPU when idle preserves battery, reduces heat in enclosed systems |
| Business dashboard (< 100 K points) | Syncfusion or DevExpress | CPU rendering sufficient at this scale; broad UI suite provides other controls |
| Signal processing with volume rendering | LightningChart — DirectX + signal tools | Built-in signal tools and volume rendering for specialized DSP workflows |
| Laptop deployment, multiple charts, long sessions | ProEssentials — zero idle cost | 8 idle charts = 0 % GPU. SciChart / LightningChart = 480 fps of wasted renders |
Das Fazit zur Leistung
ProEssentials' Kombination aus GPU Compute Shaders, On-Demand-Rendering, verlustfreier Datentreue und Zero-Copy-Datenladen ist architektonisch einzigartig unter WPF-Charting-Bibliotheken. Keine andere Bibliothek erreicht alle vier gleichzeitig. SciChart bietet GPU-Geschwindigkeit, aber mit kontinuierlichem Stromverbrauch und Daten-Resampling. LightningChart bietet verlustfreies Rendering, aber mit kontinuierlichem Stromverbrauch und MVVM-brechenden API-Einschränkungen. Syncfusion und DevExpress bieten einfache Integration, aber mit niedrigeren Leistungsobergrenzen — Syncfusion erreicht bei etwa 16 Millionen Punkten Speichergrenzen, und DevExpress kann mit aktiviertem Resampling auf etwa 50 Millionen kommen, aber bei extremen Speicherkosten.
Für wissenschaftliche, technische, medizinische, industrielle und jede Anwendung, bei der große Datensätze, Datentreue und Energieeffizienz wichtig sind — ProEssentials' Rendering-Architektur ist das stärkste technische Fundament, das in einer WPF-Charting-Komponente verfügbar ist.
100 M Punkte: Vollständiger Code
C#-Code Seite an Seite, der zeigt, wie jede Bibliothek 100 Millionen Datenpunkte verarbeitet.
Mehr erfahrenPreise & Support
5-Jahres-TCO-Vergleich, Support-Ticket-Limits und wer tatsächlich antwortet, wenn Sie Hilfe brauchen.
Mehr erfahrenKI-Code-Unterstützung
Wie pe_query.py KI-generierten Diagramm-Code gegen die kompilierte DLL validiert.
Mehr erfahrenFragen zur Leistung?
ProEssentials-Support ist kostenlos, unbegrenzt und wird direkt von den Entwicklern bereitgestellt, die die Rendering-Engine gebaut haben. Fragen Sie uns alles über GPU-Architektur, Datenladen oder Echtzeit-Leistung.
Kontaktieren Sie das ProEssentials-Team →Unsere Aufgabe
Ihr Erfolg ist unser höchstes Ziel, indem wir Ihrem Unternehmen und Ihren Endbenutzern den einfachsten und professionellsten Nutzen bieten.
Wir sind Ingenieure
ProEssentials wurde von professionellen Elektroingenieuren erschaffen, die ihre eigenen Charting-Komponenten benötigten. Treten Sie unserer großen Liste von Top-Engineering-Unternehmen bei, die ProEssentials einsetzen.
Danke sehr
Vielen Dank, dass Sie ein ProEssentials-Kunde sind, und vielen Dank, dass Sie die ProEssentials-Charting-Engine recherchieren.