WinForms Chart GPU-Performance:

Die meisten WinForms-Charting-Vergleiche gehen von einer falschen Prämisse aus: dass WinForms das veraltete, langsamere Geschwisterkind von WPF sei und dass ernsthaftes Charting großer Datenmengen zu WPF gehöre. Für ProEssentials trifft das Gegenteil zu. Die WinForms-Schnittstelle koppelt Direct3D direkt an den Gerätekontext des Fensters (hDC) und umgeht damit den Render-to-Texture- und D3DImage-Compositor-Schritt, den WPF strukturbedingt erfordert — und in unseren Tests macht das den nativen WinForms-Pfad end-to-end rund 5 % schneller als dieselbe Engine, die ein WPF-Control antreibt.

Diese Seite erklärt, warum das so ist, vergleicht die WinForms-Rendering-Architektur der acht Charting-Optionen, die Entwickler tatsächlich evaluieren, und verweist auf vier reproduzierbare Clone-and-Run-Demos, damit jede Aussage hier überprüfbar ist und nicht auf Vertrauen beruht. Die Kernaussage ist einfach: Unter WinForms rendert ProEssentials 100 Millionen verlustfreie Punkte in etwa 15 ms ohne Datenverdopplung — und das auf der Schnittstelle, die architektonisch seine schnellste ist.

Reproduzieren Sie jede Zahl auf dieser Seite selbst. Vier WinForms-Demos, klonen und F5 drücken:

Der hDC-Vorteil: Warum natives WinForms WPF auf derselben Engine schlägt

Jede Charting-Bibliothek, die unter WPF mit der GPU rendert, trägt eine unvermeidbare architektonische Last. WPF besitzt den Bildschirm über seine eigene Composition-Engine (die Media Integration Layer). Ein Control kann Direct3D nicht einfach auf den Bildschirm zeichnen, wie es ein natives Fenster kann — der WPF-Compositor besitzt diese Pixel. Um GPU-Inhalte einzuspeisen, muss die Bibliothek ihre Direct3D-Szene in eine Off-Screen-Textur rendern, diese Textur über ein D3DImage (oder die neuere Composition-Interop) an WPF übergeben und sie vom WPF-Compositor beim nächsten Compositor-Tick in den Visual Tree einblenden lassen.

Dieser Umweg ist nicht kostenlos. Der fertige GPU-Frame wird in eine geteilte Surface kopiert, über den Direct3D- und den WPF-Rendering-Thread synchronisiert und dann von WPF ein zweites Mal komponiert, bevor er das Glas erreicht. Jeder Frame zahlt für einen Texturkopie- und einen Compositor-Sync-Aufwand, der nichts damit zu tun hat, wie schnell der Chart selbst gezeichnet wurde.

Das ProEssentials-WinForms-Control hat keine solche Last. Als Standard-System.Windows.Forms.Control besitzt es ein echtes Win32-Fensterhandle und einen echten Gerätekontext. Direct3D ist direkt an diesen hDC gekoppelt, sodass der vom Compute Shader konstruierte Frame direkt an das Fenster ausgegeben wird — kein Render-to-Texture, keine D3DImage-Übergabe, kein zweites Compositing. Dasselbe gilt für die C++/MFC- und Delphi/VCL-Schnittstellen, die noch direkter an den hDC binden, da es gar keine Managed-Schicht gibt.

Das praktische Ergebnis: Über repräsentative Datensätze hinweg misst die native WinForms-Schnittstelle end-to-end rund 5 % schneller als dieselbe ProEssentials-Engine, die ein WPF-Control antreibt. Der Compute Shader, der Zero-Copy-Datenpfad und das On-Demand-Frame-Modell sind Byte für Byte identisch — der einzige Unterschied ist, dass WinForms den WPF-Compositor vollständig überspringt. WinForms ist nicht die Kompromiss-Schnittstelle für ProEssentials. Es ist die schnelle.

Die WinForms-Charting-Landschaft ist nicht die WPF-Landschaft

Beim Wechsel von WPF zu WinForms ändert sich das Wettbewerbsfeld — und, noch wichtiger, die Hochleistungstechnologie der meisten Mitbewerber kommt nicht mit. Mehrere Bibliotheken bewerben aggressive Fast Series oder GPU-Rendering, stellen diese Pfade aber nur unter WPF, WinUI oder UWP bereit. Unter WinForms fallen sie auf GDI+, auf eine funktionsreduzierte Fast-View oder auf gar nichts zurück. Zu verstehen, was wovon zutrifft, zählt mehr als jede einzelne Benchmark-Zahl.

ProEssentials: Direct3D Compute Shaders, hDC-gekoppelt

ProEssentials-WinForms-Controls (PegoWin, PesgoWin, Pe3doWin, PepsoWin, PepcoWin) sind Standard-Abkömmlinge von System.Windows.Forms.Control, die Direct3D Compute Shaders verwenden, um das Chart-Bild vollständig auf der GPU zu konstruieren. Tausende GPU-Kerne verarbeiten jeden Datenpunkt parallel; die CPU durchläuft das Array nie. Der fertige Frame wird direkt an den hDC des Controls ausgegeben.

Das Rendering großer Datenmengen wird mit wenigen Eigenschaften aktiviert — PeData.ComputeShader = true plus den StagingBufferX/Y/Z-Flags — und Daten werden über UseDataAtLocation() bereitgestellt, das einen Zeiger auf Ihr bestehendes Array speichert, statt es zu kopieren. Es gibt keine Float-zu-Double-Konvertierung, keine Objekt-pro-Punkt-Allokation und keine Managed-Schleife über die Daten.

Die Pipeline läuft On-Demand: Sie zeichnet nur, wenn sich Daten oder Viewport tatsächlich ändern. Ein inaktiver Chart verbraucht null GPU. Dies ist dieselbe Engine, dieselben Shader und derselbe Zero-Copy-Pfad wie beim WPF-Control — aber ohne den Render-to-Texture-Compositor-Schritt von WPF, weshalb der WinForms-Pfad schneller misst.

Berichteter Durchsatz auf einer RTX 3090: 100 Millionen verlustfreie Punkte in ~15 ms konstruiert, mit end-to-end Frameraten um 15 FPS einschließlich vollständiger 100M-Punkt-Datenübertragung pro Frame — kein Resampling, kein Downsampling, keinerlei Datenreduktion.

SciChart: Kein natives WinForms-Control

SciChart wird oft als das schnellste WPF-Chart genannt, hat aber überhaupt kein natives WinForms-Control. Die eigene Dokumentation von SciChart gibt an, dass WinForms nur durch Integration mit WPF unterstützt wird — das heißt, indem das WPF-SciChartSurface in einem Microsoft-ElementHost gehostet wird.

Das bedeutet, dass ein SciChart-WinForms-Deployment jede Eigenschaft von WPF erbt — einschließlich des Render-to-Texture-Compositor-Pfads — plus die gut dokumentierten ElementHost-Interop-Einschränkungen rund um Mausereignisse, Fokus und Z-Reihenfolge. Sie betreiben ein WPF-Control im WinForms-Kostüm.

Für eine echte native WinForms-Anwendung — besonders Datenerfassungssoftware mit Win32/MFC-Herkunft — gibt es keine erstklassige SciChart-Option. Der Performance-Spitzenname der Kategorie stellt schlicht keinen nativen WinForms-Eintrag.

LightningChart: Nativ, GPU — kontinuierliche Schleife

LightningChart ist der stärkste echte native WinForms-Konkurrent. Es rendert mit Low-Level-DirectX statt GDI+ und bewirbt sehr hohe Kapazitäten (ältere Unterlagen nannten bis zu 1 Milliarde Punkte; aktuelles Marketing nennt Zahlen im Milliardenbereich).

Seine Kompromisse entsprechen der WPF-Seite: Eine kontinuierliche DirectX-Render-Schleife hält die GPU aktiv, selbst wenn sich nichts ändert, sodass auch inaktive Dashboards weiterhin Frames zeichnen; und das Deployment erforderte historisch eine Online-Aktivierung mit Reaktivierungsgebühr — ein echtes Hindernis für luftspaltgetrennte Industrie- und Verteidigungssysteme.

Verlustfreies Rendering im großen Maßstab hängt von der Wahl des korrekten Serientyps ab; der falsche Typ verschlechtert die Performance stillschweigend um Größenordnungen, ohne Compile-Zeit-Warnung.

DevExpress: SwiftPlot (nur WinForms, funktionsreduziert)

DevExpress ist interessant, weil seine schnelle Großdaten-View, SwiftPlotSeriesView, nur unter WinForms existiert — sie gibt es im WPF-ChartControl nicht. DevExpress bewirbt die Fähigkeit, über 20 Millionen Punkte ohne Vorverarbeitung zu visualisieren, und sein optionaler DirectX-Modus ist bei UHD bis zu 9× schneller als GDI+.

SwiftPlot erreicht seine Geschwindigkeit durch einen erleichterten Generierungsalgorithmus, der bewusst Funktionen weglässt, die anderen View-Typen zur Verfügung stehen, und das zugrunde liegende Datenmodell ist weiterhin Objekt-pro-Punkt. Bei 100M Punkten bedeutet das, Milliarden Bytes an DataPoint-Objekten zu allokieren, bevor das Rendering beginnen kann.

Es ist eine fähige Echtzeit-View für den Bereich von zehntausenden bis wenigen Millionen, aber es ist ein CPU/GDI+-verwurzelter Pfad mit optionalem DirectX — keine Compute-Shader-Engine und nicht Zero-Copy.

Syncfusion: Keine WinForms-Fast-Series

Syncfusion bewirbt Fast Series (FastLineSeries, FastLineBitmapSeries) für Daten mit hohem Volumen — doch diese existieren nur unter WPF, WinUI und UWP. Unter WinForms gibt es keinen Fast-Series-Pfad. Das eigene Support-Team von Syncfusion erfasste eine Feature-Anfrage, um Fast Series zum WinForms-Chart hinzuzufügen, und erklärte, es gebe keinen unmittelbaren Plan zur Umsetzung.

Selbst unter WPF ist der schnelle Pfad CPU-basiert: FastLineBitmapSeries zeichnet in eine WriteableBitmap und rendert eine Million Punkte in wenigen Sekunden. Syncfusion stellte zudem seine DirectX-Series ein. WinForms verlässt sich daher auf Standard-GDI+-Rendering ohne GPU-Beschleunigung.

Syncfusion bleibt eine starke breite UI-Suite für Business-Dashboards unter ~100K Punkten, ist aber keine Hochvolumen-Engine für wissenschaftliches WinForms-Charting.

ComponentOne FlexChart, Telerik, ScottPlot, MS Chart

ComponentOne FlexChart (Mescius/GrapeCity) ist ein fähiges natives WinForms-Control mit GDI+-Standard und einem optionalen Direct2D-Hochleistungsmodus — doch sein eigener veröffentlichter Performance-Benchmark testet nur von 100 bis 30.000 Punkten, drei bis vier Größenordnungen unter dem 100M-Maßstab.

Telerik RadChartView ist unter WinForms GDI+-basiert; seine hardwarebeschleunigten Direct2D/Skia-Optionen sind nur WPF. Teleriks eigenes Team erklärte, dass 90.000 Punkte zu viel für RadChartView seien, und empfiehlt, Daten vor dem Plotten zu aggregieren/zu mitteln — ein verlustbehafteter Workaround.

ScottPlot ist die dominierende kostenlose/Open-Source-Option (CPU über System.Drawing, dann SkiaSharp). Es verlässt sich auf Datendezimierung zu einer repräsentativen Teilmenge, und die Initialisierung sehr großer Plots (10M+ Punkte) dauert 100+ ms; sein Maintainer merkt an, dass das Managed-zu-Native-Marshalling von Punkt-Arrays die grundlegende Obergrenze ist. Das veraltete Microsoft Chart (System.Windows.Forms.DataVisualization.Charting) ist offiziell als veraltet eingestuft, GDI+-basiert, entstand als einfaches Dundas Chart und wird auf modernem .NET (5–8) nicht unterstützt.

On-Demand vs kontinuierliches Rendering — dieselbe Geschichte, WinForms-Edition

Die Unterscheidung On-Demand versus kontinuierlich von der WPF-Seite gilt unter WinForms identisch und bleibt der am meisten unterschätzte Faktor bei der Chart-Auswahl. ProEssentials zeichnet nur, wenn sich Daten ändern; die kontinuierliche DirectX-Schleife von LightningChart zeichnet ungeachtet dessen. Bei einem nativen WinForms-Control wird der On-Demand-Frame direkt an den hDC ausgegeben, sodass die Idle-GPU-Einsparungen ohne Compositor-Overhead kommen, wenn Frames tatsächlich auftreten.

On-Demand-Rendering ist während des aktiven Renderings nicht langsamer — der Compute-Shader-Pfad ist genauso schnell. Der Unterschied liegt darin, was zwischen den Frames geschieht: ProEssentials tut nichts, während eine Bibliothek mit kontinuierlicher Schleife GPU und Lüfter damit beschäftigt hält, identische Pixel neu zu zeichnen.

Wie der GPU-Compute-Shader-Pfad funktioniert

Ohne ComputeShader durchläuft die CPU jeden Punkt sequenziell auf einem einzigen Kern, um Vertex-Daten zu erstellen. Mit PeData.ComputeShader = true erledigt die GPU diese Arbeit über potenziell 2.000+ Kerne parallel. Gemessene Auswirkung auf eine 2,5M-Punkt-LiDAR-Wolke: Das Click-to-First-Paint sinkt von rund 3 Sekunden CPU-Vertex-Konstruktion auf im Wesentlichen sofort.

Die StagingBuffer-Flags allokieren GPU-zugängliche Zwischenspeicherbereiche, die einen effizienten CPU-zu-GPU-Upload ermöglichen, ohne die Render-Pipeline während der Übertragung anzuhalten. Kommentieren Sie die vier Zeilen aus, um bewusst den langsamen CPU-Pfad zu nehmen — nützlich für Vorher-Nachher-Vergleiche:

// 3D-Scatter, GPU-Vertex-Konstruktion, ausgegeben an den WinForms-hDC
Pe3do1.PeData.ComputeShader  = true;
Pe3do1.PeData.StagingBufferX = true;
Pe3do1.PeData.StagingBufferY = true;
Pe3do1.PeData.StagingBufferZ = true;

Das Fazit zur WinForms-Performance

Bei ProEssentials ist WinForms kein Downgrade gegenüber WPF — es ist die schnellere Schnittstelle, weil Direct3D an den hDC des Fensters bindet und den Render-to-Texture-Compositor-Schritt von WPF überspringt, für rund 5 % end-to-end-Vorsprung auf derselben Engine. Sie erhalten GPU Compute Shaders, On-Demand-Rendering, verlustfreie Treue und Zero-Copy-Laden, mit 100M verlustfreien Punkten in ~15 ms.

Unter den Alternativen hat SciChart kein natives WinForms-Control (nur WPF-in-ElementHost), Syncfusion hat keine WinForms-Fast-Series, Telerik endet bei einigen zehntausend Punkten, bevor es Aggregation empfiehlt, ComponentOne benchmarkt nur bis 30K, ScottPlot dezimiert, und das Microsoft Chart ist veraltet. LightningChart und DevExpress sind die echten nativen Anwärter — beide fähig, beide mit Kompromissen (Stromverbrauch durch kontinuierliche Schleife und Aktivierung; funktionsreduzierte Objekt-pro-Punkt-Fast-View). Für natives WinForms-, C++/MFC- und Delphi/VCL-Charting, bei dem Datentreue und großmaßstäbliche Performance zählen, ist die hDC-gekoppelte Compute-Shader-Engine von ProEssentials das stärkste technische Fundament, das verfügbar ist.

100M Punkte: Vollständiger Code

C#-Code im direkten Vergleich, der genau zeigt, wie jede Bibliothek 100 Millionen Datenpunkte verarbeitet.

Preise & Support

5-Jahres-TCO-Vergleich, Support-Ticket-Limits und wer tatsächlich antwortet, wenn Sie Hilfe brauchen.

KI-Code-Unterstützung

Wie pe_query.py KI-generierten Chart-Code gegen die kompilierte DLL validiert.

Technische Referenzen & Ground-Truth-Quellen

Jede Mitbewerber-Aussage auf dieser Seite stammt aus der eigenen Dokumentation, den Benchmarks oder den Support-Aussagen des Anbieters. Überprüfen Sie sie direkt: