WinForms チャート GPU パフォーマンス:

WinForms チャート比較の多くは、誤った前提から始まります: WinForms は WPF のレガシーで遅い兄弟であり、本格的な大規模データ チャートは WPF でやるべきだ、と。ProEssentials では逆が真です。WinForms インターフェイスは Direct3D をウィンドウのデバイスコンテキスト（hDC）へ直接結び付け、WPF が構造的に必要とする render-to-texture と D3DImage コンポジターの中継をバイパスします — 当社のテストでは、これによりネイティブ WinForms パスは、まったく同じエンジンで WPF コントロールを駆動する場合よりエンドツーエンドで約5%高速です。

このページではその理由を説明し、開発者が実際に評価する8つのチャート選択肢の WinForms レンダリング アーキテクチャを比較し、再現可能なクローンしてすぐ動く4つのデモを示します — このページのすべての主張は、信じるのではなく検証できます。要点はシンプルです: WinForms 上で、ProEssentials は1億のロスレス ポイントを約15ミリ秒で、データ複製ゼロでレンダリングします。しかも、アーキテクチャ上それが最速となるインターフェイスの上で。

このページのすべての数字をご自身で再現してください。4つの WinForms デモ、クローンして F5 を押すだけ:

hDC の優位性: 同じエンジンでネイティブ WinForms が WPF に勝つ理由

WPF で GPU レンダリングするすべてのチャートライブラリは、避けられないアーキテクチャ上の税を払います。WPF は独自のコンポジション エンジン（Media Integration Layer）を通じて画面を所有します。ネイティブ ウィンドウのように、コントロールが Direct3D を画面へ直接描くことはできません — それらのピクセルは WPF のコンポジターのものだからです。GPU コンテンツを注入するには、ライブラリは Direct3D シーンをオフスクリーン テクスチャへレンダリングし、そのテクスチャを D3DImage（または新しいコンポジション相互運用）経由で WPF に渡し、次のコンポジター ティックで WPF のコンポジターにビジュアルツリーへ合成させなければなりません。

この往復はタダではありません。完成した GPU フレームは共有サーフェスへコピーされ、Direct3D と WPF のレンダリングスレッド間で同期され、さらに画面に届く前に WPF によってもう一度合成されます。チャート自体がどれだけ速く描かれたかとは無関係に、すべてのフレームがテクスチャコピーとコンポジター同期のコストを払うのです。

ProEssentials の WinForms コントロールにはこの税がありません。標準の System.Windows.Forms.Control として、本物の Win32 ウィンドウハンドルと本物のデバイスコンテキストを所有します。Direct3D はその hDC に直接結合されており、コンピュートシェーダーで構築されたフレームはウィンドウへ直接提示されます — render-to-texture なし、D3DImage の受け渡しなし、二度目の合成なし。C++/MFC と Delphi/VCL のインターフェイスも同様で、マネージド レイヤーがまったく存在しないぶん、さらに直接的に hDC へ結び付きます。

実用上の結果: 代表的なデータセット全体で、ネイティブ WinForms インターフェイスは、同一の ProEssentials エンジンで WPF コントロールを駆動する場合よりエンドツーエンドで約5%高速と計測されます。コンピュートシェーダー、ゼロコピー データパス、オンデマンド フレームモデルはバイト単位で同一です — 唯一の違いは、WinForms が WPF のコンポジターを完全にスキップすることです。WinForms は ProEssentials にとって妥協のインターフェイスではありません。最速のインターフェイスです。

WinForms チャートの勢力図は WPF の勢力図ではない

WPF から WinForms へ移ると、競合の顔ぶれが変わり — さらに重要なことに — 多くのライバルの高性能テクノロジーは付いてきません。攻撃的に「fast series」や GPU レンダリングを宣伝するいくつかのライブラリは、それらのパスを WPF、WinUI、UWP でしか公開していません。WinForms では GDI+ へ、機能を削った高速ビューへ、あるいは何もないところへフォールバックします。どれがどれかを理解することは、どんな単一のベンチマーク数値よりも重要です。

ProEssentials: Direct3D コンピュートシェーダー、hDC 結合

ProEssentials の WinForms コントロール（PegoWin、PesgoWin、Pe3doWin、PepsoWin、PepcoWin）は標準の System.Windows.Forms.Control の子孫で、Direct3D コンピュートシェーダーを使ってチャート画像を完全に GPU 上で構築します。数千の GPU コアがすべてのデータポイントを並列処理し、CPU は配列を一切走査しません。完成したフレームはコントロールの hDC へ直接提示されます。

大規模データ レンダリングは少数のプロパティで有効化します — PeData.ComputeShader = true と StagingBufferX/Y/Z フラグ — そしてデータは UseDataAtLocation() で供給します。これは既存の配列をコピーするのではなく、そのポインタを保持します。float から double への変換も、ポイントごとのオブジェクト割り当ても、データに対するマネージド ループもありません。

パイプラインはオンデマンドで動作します: データまたはビューポートが実際に変化したときだけ描画します。アイドル状態のチャートの GPU 消費はゼロです。これは WPF コントロールが使うのと同じエンジン、同じシェーダー、同じゼロコピー パスです — ただし WPF の render-to-texture コンポジター中継がないため、WinForms パスのほうが速く計測されます。

RTX 3090 での報告スループット: 1億のロスレス ポイントを約15ミリ秒で構築し、毎フレーム1億ポイント全データ転送を含むエンドツーエンドのフレームレートは約15 FPS — リサンプリングなし、ダウンサンプリングなし、いかなるデータ削減もなし。

SciChart: ネイティブ WinForms コントロールなし

SciChart は最速の WPF チャートとして広く引用されますが、ネイティブの WinForms コントロールがまったくありません。SciChart 自身のドキュメントが、WinForms は「WPF との統合を通じて」のみサポートされると述べています — つまり、WPF の SciChartSurface を Microsoft の ElementHost 内にホストする方式です。

これは、SciChart の WinForms デプロイが WPF のすべての特性 — render-to-texture コンポジターパスを含む — に加え、マウスイベント、フォーカス、Z オーダーに関するよく知られた ElementHost 相互運用の注意点を引き継ぐことを意味します。WinForms の衣装を着た WPF コントロールを動かしているのです。

真のネイティブ WinForms アプリケーション — 特に Win32/MFC の系譜を持つデータ収集ソフトウェア — には、第一級の SciChart の選択肢は存在しません。このカテゴリーの看板的な高性能ブランドは、ネイティブ WinForms のエントリーをそもそも出していないのです。

LightningChart: ネイティブ、GPU — 連続ループ

LightningChart は、真にネイティブな WinForms のライバルとして最強です。GDI+ ではなく低レベル DirectX でレンダリングし、非常に高い容量を宣伝しています（過去の資料では最大10億ポイント、現行マーケティングでは数十億という数字を主張）。

そのトレードオフは WPF ページと同じです: 連続 DirectX レンダーループは何も変わらなくても GPU を稼働させ続けるため、アイドル状態のダッシュボードもフレームを描き続けます。また、デプロイには歴史的にオンライン アクティベーションと再アクティベーション料金が必要でした — エアギャップされた産業・防衛システムには現実的な障害です。

大規模スケールでのロスレス レンダリングは正しい系列タイプの選択に依存します。誤ったタイプはコンパイル時の警告なしに、性能を桁違いに静かに劣化させます。

DevExpress: SwiftPlot（WinForms 専用、機能削減版）

DevExpress が興味深いのは、その高速大規模データビュー SwiftPlotSeriesView が WinForms 専用である点です — WPF の ChartControl には存在しません。DevExpress は「前処理なしで2,000万ポイント超」を可視化できると宣伝し、オプションの DirectX モードは UHD で GDI+ より最大9倍高速です。

SwiftPlot は、他のビュータイプで使える機能を意図的に省いた「軽量化」生成アルゴリズムで速度を達成しており、基盤のデータモデルは依然としてポイントごとのオブジェクトです。1億ポイントでは、レンダリングを始める前に数十億バイトの DataPoint オブジェクトを割り当てることになります。

数万から数百万程度の範囲では有能なリアルタイム ビューですが、これは CPU/GDI+ に根ざしたパスにオプションの DirectX が付いたもの — コンピュートシェーダー エンジンではなく、ゼロコピーでもありません。

Syncfusion: WinForms に Fast Series なし

Syncfusion は大容量データ向けに「Fast Series」(FastLineSeries、FastLineBitmapSeries)を宣伝していますが、それらは WPF、WinUI、UWP にしか存在しません。WinForms には高速系列のパスがありません。Syncfusion 自身のサポートチームが WinForms チャートへの fast series 追加の機能リクエストを記録し、実装の当面の計画はないと述べています。

WPF 上でも、高速パスは CPU ベースです: FastLineBitmapSeries は WriteableBitmap に描画し、100万ポイントのレンダリングに「数秒」かかります。Syncfusion は DirectX 系列も廃止しました。したがって WinForms は GPU アクセラレーションのない標準 GDI+ レンダリングに頼ることになります。

Syncfusion は約10万ポイント未満のビジネス ダッシュボード向けの幅広い UI スイートとしては強力ですが、大容量の科学向け WinForms チャートエンジンではありません。

ComponentOne FlexChart、Telerik、ScottPlot、MS Chart

ComponentOne FlexChart（Mescius/GrapeCity）は GDI+ デフォルトとオプションの Direct2D「高性能」モードを持つ有能なネイティブ WinForms コントロールです — しかし、自社公開の性能ベンチマークは100〜30,000ポイントしかテストしておらず、1億スケールより3〜4桁下です。

Telerik RadChartView は WinForms では GDI+ ベースで、ハードウェア アクセラレーションの Direct2D/Skia オプションは WPF 専用です。Telerik 自身のチームが、RadChartView には90,000ポイントは「多すぎる」と述べ、プロットの前にデータを集約・平均して削減することを推奨しています — ロッシーな回避策です。

ScottPlot は支配的な無料/オープンソースの選択肢です(System.Drawing、その後 SkiaSharp による CPU)。代表サブセットへのデータ間引きに依存し、超大規模プロット（1,000万ポイント以上）の初期化には100ミリ秒以上かかります。メンテナー自身が、ポイント配列のマネージド→ネイティブ マーシャリングが根本的な上限だと述べています。レガシーの Microsoft Chart（System.Windows.Forms.DataVisualization.Charting）は公式に非推奨で、GDI+ ベース、出自は基本的な Dundas Chart であり、モダンな .NET（5〜8）ではサポートされません。

オンデマンド対連続レンダリング — 同じ話の WinForms 版

WPF ページで述べたオンデマンド対連続の違いは WinForms でもまったく同じく当てはまり、チャート選定で最も過小評価されている要素であり続けています。ProEssentials はデータが変化したときだけ描画します。LightningChart の連続 DirectX ループはお構いなしに描画します。ネイティブ WinForms コントロールでは、オンデマンドのフレームが hDC へ直接提示されるため、アイドル時の GPU 節約に加え、フレームが発生したときにもコンポジター オーバーヘッドがありません。

オンデマンド レンダリングはアクティブなレンダリング中に遅くなるわけではありません — コンピュートシェーダー パスは同じだけ速いのです。違いはフレームとフレームの間に何が起こるかです: ProEssentials は何もしません。連続ループのライブラリは、同一のピクセルを再描画するために GPU とファンを稼働させ続けます。

GPU コンピュートシェーダー パスの仕組み

ComputeShader なしでは、CPU が単一コアで各ポイントを順番に走査して頂点データを構築します。PeData.ComputeShader = true にすると、GPU が潜在的に2,000以上のコアでこの作業を並列に行います。250万ポイントの LiDAR クラウドでの計測効果: クリックから最初の描画までが、約3秒の CPU 頂点構築から実質的に瞬時へ短縮されます。

StagingBuffer フラグは、転送中にレンダーパイプラインを停止させない効率的な CPU→GPU アップロードを可能にする、GPU からアクセス可能な中間メモリ領域を割り当てます。4行をコメントアウトすれば意図的に遅い CPU パスを通れます — 前後比較に便利です:

// 3D 散布図、GPU 頂点構築、WinForms の hDC へ提示
Pe3do1.PeData.ComputeShader  = true;
Pe3do1.PeData.StagingBufferX = true;
Pe3do1.PeData.StagingBufferY = true;
Pe3do1.PeData.StagingBufferZ = true;

WinForms パフォーマンスの結論

ProEssentials において、WinForms は WPF からのダウングレードではありません — より速いインターフェイスです。Direct3D がウィンドウの hDC に結合し、WPF の render-to-texture コンポジター中継をスキップするため、同じエンジンでエンドツーエンド約5%の優位があります。GPU コンピュートシェーダー、オンデマンド レンダリング、ロスレスの忠実度、ゼロコピー読み込みが手に入り、1億のロスレス ポイントを約15ミリ秒でレンダリングします。

代替の中では、SciChart にはネイティブ WinForms コントロールがなく（WPF-in-ElementHost のみ）、Syncfusion には WinForms の fast series がなく、Telerik は数万ポイント程度で頭打ちになり集約を推奨し、ComponentOne のベンチマークは3万ポイントまで、ScottPlot は間引きし、Microsoft Chart は非推奨です。LightningChart と DevExpress が真のネイティブな対抗馬です — どちらも有能で、どちらもトレードオフを抱えています（連続ループの電力消費とアクティベーション、機能を削ったポイントごとオブジェクトの高速ビュー）。データ忠実度と大規模性能が重要なネイティブ WinForms・C++/MFC・Delphi/VCL チャートには、ProEssentials の hDC 結合コンピュートシェーダー エンジンが、入手可能な最も強固な技術基盤です。

1億ポイント: 完全なコード

各ライブラリが1億データポイントをどう扱うかを正確に示す、並列の C# コード。

価格とサポート

5年間の TCO 比較、サポートチケット制限、そして助けが必要なとき実際に誰が答えるのか。

AI コード支援

pe_query.py が AI 生成のチャートコードをコンパイル済み DLL と照合検証する仕組み。

技術リファレンスと一次情報源

このページの競合に関するすべての主張は、各ベンダー自身のドキュメント、ベンチマーク、サポート上の発言が出典です。直接ご確認ください: