WPF チャート GPU パフォーマンス:
5ライブラリ アーキテクチャ比較
WPF チャート GPU パフォーマンス:
Compute Shader vs ゲームエンジン ループ vs CPU レンダリング
レンダリングエンジンは、チャートライブラリにおける最も重大なアーキテクチャ上の決定です。何ポイントをプロットできるか、全ポイントを見るのかリサンプリングされた近似を見るのか、チャートがどれだけメモリを消費するか、どれだけ電力を消費するか、そしてダッシュボードを開いた瞬間にノートPCのファンが回り出すかどうかを決めます。それなのに、ほとんどの比較ページはこれを「GPU アクセラレーション — あり / なし」という1つのチェックマークに還元してしまいます。エンジニアリング上の判断を下すには、その情報ではまったく足りません。
このページでは、最も一般的な5つの WPF チャートライブラリが使う4つの異なるレンダリングアーキテクチャを、それぞれの動作原理、トレードオフ、そして実際のアプリケーションにとっての意味という具体的な技術的詳細とともに解説します。
See these world-class charting technologies yourself: clone, build, run the 8M-point real-time zero-copy circular-buffer demo on GitHub.Reproduce these numbers yourself: clone, build, run the 100M-point demo on GitHub.
クイックリファレンス: レンダリングアーキテクチャ比較
| 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) |
4つのレンダリングアーキテクチャの解説
市場のすべての WPF チャートライブラリは、4つのアーキテクチャ カテゴリーのいずれかに該当します。これらのカテゴリーを理解することは、ベンチマークの数値を読むことより重要です。アーキテクチャはそのライブラリが到達し得る上限を決め、どんな最適化も根本的に制約のあるアーキテクチャを克服できないからです。
ProEssentials: Direct3D Compute Shader
ProEssentials は Direct3D Compute Shader — 科学シミュレーション、機械学習推論、物理エンジンで使われるのと同じ GPU テクノロジー — を用いて、チャート画像を完全に GPU 上で構築します。これは GPU を単に三角形の描画に使う方式（ゲームエンジン方式）とはアーキテクチャ的に異なります。
Compute Shader アーキテクチャでは、CPU は生のデータ配列を一度だけ GPU メモリへ送ります。その後 GPU がシェーダープログラムを実行し、すべてのデータポイントを並列に処理します — 数千の GPU コアがそれぞれデータセットの一部を同時に担当します。シェーダーが各ポイントのピクセル位置、色、可視性を決定し、結果を GPU テクスチャへ直接書き込み、完成した画像が画面にプレゼントされます。
決定的な利点は、CPU がデータを一切反復しないことです。1億個の float を歩くマネージドループはありません。float から double への変換もありません。中間オブジェクトのアロケーションもありません。GPU がすべての作業を行い、それを大規模並列で実行します — 現代の GPU は2,000〜10,000のコアをすべて同時に稼働させます。
同じく重要な点として、ProEssentials はデータが実際に変化したときにのみ、このパイプラインを実行します。チャートが画面上でアイドル状態にあるとき（ダッシュボードやレポートでは、これがその大半の時間を占めます）、GPU の処理はまさにゼロです。このオンデマンド方式により、ProEssentials は必要なときには GPU の速度を得られ、不要なときには消費電力がゼロになります。そしてレンダリングエンジンがネイティブ C++ であるため、この同一の compute-shader パイプラインが WPF、WinForms、WinUI 3 の各コントロールを等しく駆動します。他のあらゆる WinUI チャートがマネージド XAML を介して描画するのに対し、WinUI 3 アプリケーションは同じ GPU ネイティブなレンダリングを得られます。このネイティブエンジンは、読み込み時にアーキテクチャに合致したビルド（.NET 8 および .NET 10 におけるネイティブ ARM64 ビルド PEGRPARM64I.DLL を含む）をバインドするため、ホストアプリケーションの EXE が x64 としてビルドされている場合を除き、あらゆるケースでネイティブ ARM64 として描画します。
Compute shader は GPU 上でデータを並列処理します。オンデマンドレンダリングにより、アイドル時の GPU コストはゼロになります。この組み合わせ、すなわち GPU の速度とオンデマンドの省資源性の両立は、WPF および WinUI のチャートライブラリの中で ProEssentials に固有のものです。
SciChart: GPU ゲームエンジン型レンダリングループ
SciChart はゲームエンジン式のレンダリングパイプラインを使います。ライブラリは毎秒約60回（約16ミリ秒ごと）発火する連続レンダーループを維持し、何かが変わったかどうかに関係なく毎フレーム チャートを再描画します。
このアーキテクチャは、画面の内容が絶えず変化し滑らかなアニメーションが最優先される、ゲームやトレーディング端末の世界に由来します。SciChart はデータを GPU 頂点バッファへ変換し、従来型のグラフィックスパイプライン — 頂点シェーダー、ラスタライザー、ピクセルシェーダー — を通してレンダリングします。3Dゲームのシーンを描くのと同じパイプラインです。
この方式の強みはアニメーションの滑らかさです。ループが常に回っているため、データやビューポートへのあらゆる変更が次のフレーム、通常16ミリ秒以内に現れます。ローソク足、ティック、板情報が絶えず更新される金融トレーディング端末のようなアプリケーションでは、この連続ループが情報の鮮度を保証します。
しかし連続ループにはコストがあります。SciChart はデータが変わっていなくても毎秒60回フルチャートを再描画します。8つの SciChart サーフェスを持つダッシュボードはアイドル状態でも毎秒480フレームの同一出力を生成し続けます。GPU は稼働し続け、ファンが回り出すこともあり、電力消費は一定です。SciChart にはレンダーループを無効化する仕組みもありますが、デフォルトの挙動ではなく、多くの開発者はその存在に気づきません。
大規模データセットで60fpsを維持するため、SciChart はデータをビューポートのピクセル幅の約2倍までリサンプリングします。幅1,920ピクセルでは、1億ポイントのデータセットが約3,840の代表ポイントに削減されて描画されます。全データはメモリに保持されますが、99.996%は任意のフレームで描画されません。つまり異常、狭いスパイク、サンプル点間の細部は、ズームインするまで見えません。
LightningChart: DirectX イミディエイトモード
LightningChart は DirectX を比較的低レベルで使い、DirectX API へのドローコールでチャート内容をレンダリングします。SciChart と同様に連続レンダリングループを維持するため、チャートデータが変わらなくても GPU は稼働し続けます。
LightningChart はデータを無損失でレンダリングできます — デフォルトではリサンプリングしません — これは、すべてのデータポイントが見えなければならない科学アプリケーションにおいて SciChart に対する大きな利点です。ただし1億ポイント規模でこれを実現するには、Non-Bindable チャート版とともに SampleDataSeries 型（または新しい SampleDataBlockSeries）を使う必要があり、WPF のデータバインディングと MVVM 互換性を手放すことになります。
連続レンダリングループのため、LightningChart は SciChart と同じ電力消費特性を持ちます: アイドル時も GPU は稼働し、ノートPCではファンが回ることがあり、組込みやバッテリー駆動の配備では不要な熱と電力のコストが蓄積します。LightningChart にはオンデマンド レンダリングへ切り替える簡単なプロパティがありません。
Syncfusion と DevExpress: デフォルト CPU レンダリング
Syncfusion と DevExpress はどちらもデフォルトで CPU ベースのレンダリングです。Syncfusion は WPF の WriteableBitmap — CPU がピクセル単位で塗りつぶすマネージドビットマップ — を使います。DevExpress は WPF 内蔵レンダリングと GDI+ の組み合わせに、オプションの DirectX モードと、テスト済み上限を約5,000万ポイントまで広げるリサンプリング プロパティ（AllowResample）を加えています。
CPU レンダリングは描画フェーズが本質的にシングルスレッドです。両ライブラリともデータ準備はバックグラウンドスレッドで行えますが、実際のピクセル書き込みは UI スレッドで起こります。これが固い上限を生みます: チャートは、単一の CPU コアが妥当なフレーム時間内に反復できるポイント数しか処理できません。実際には、UI がカクつき始める前のこの上限はおよそ500,000〜1,000,000ポイントです。
CPU レンダリングの利点はシンプルさと互換性です。GPU ドライバー要件も、DirectX 依存も、配布すべき VC++ 再頒布可能パッケージもありません。10万ポイント未満のアプリケーション — 大半のビジネスダッシュボード、人事分析、プロジェクト管理ツールが含まれます — にとって CPU レンダリングは十分であり、これらのベンダーが提供する幅広い UI スイートには実際の価値があります。
オンデマンド vs 連続レンダリング: ダッシュボードが実際にしていること
オンデマンドと連続レンダリングの違いは、チャートライブラリ選定で最も過小評価されている要素です。ベンチマークのスクリーンショットには一切影響しませんが、実際の配備 — 特にノートPC、組込みシステム、マルチモニター環境、チャートが他のコントロールと画面を分け合うあらゆるアプリケーション — には甚大な影響があります。
| 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 |
オンデマンド レンダリングは連続レンダリングより遅くありません。ProEssentials はアクティブなレンダリング中、SciChart や LightningChart と同じ GPU アクセラレーションの速度を達成します — Compute Shader パイプラインは同様に高速です。違いはレンダリングとレンダリングの間に何が起きるかです。ProEssentials は何もしません。SciChart と LightningChart は同一の内容を毎秒60回描き直し続けます。
データ忠実度: すべてのポイントを見るのか、近似を見るのか?
ライブラリが1億データポイントを「サポート」すると主張するとき、決定的な追加質問はこれです: 実際に1億ポイントすべてをレンダリングするのか、それとも数千にリサンプリングして近似を見せるのか? ビジネスダッシュボードならリサンプリングは許容できます — データの視覚的な形は保たれます。しかし科学・医療・エンジニアリングのアプリケーションでは、リサンプリングはあなたが見つけるべきまさにその異常やスパイクを隠しかねません。
SciChart は大規模データセットへの中核戦略として自動リサンプリングを使います。ResamplingMode が Auto（大規模データのデフォルト）の場合、ライブラリは水平ピクセルあたり約2ポイントを計算し、その代表ポイントだけをレンダリングします。幅1,920ピクセルでは、1億ポイントの折れ線チャートが約3,840ポイントとして描かれます。俯瞰ズームでは形は正しく見えますが、その3,840サンプルの間にある細かな詳細は見えません。
ProEssentials はすべてのデータポイントをレンダリングします。Compute Shader が1億の値すべてを処理し、各ポイントの正しいピクセル寄与を決定します。3つのポイントが同じピクセル列に該当する場合、シェーダーはその列の min・max・close を正しく計算し — リサンプリングなら見逃すスパイクや異常を含む、データの視覚的エンベロープを保持します。
LightningChart も正しいシリーズ型（Non-Bindable チャートの SampleDataSeries）を使えば無損失でレンダリングします。しかし誤ったシリーズ型や Bindable チャート版を選ぶと、性能は桁違いに悪化します — しかも遅いパスを選んでしまったというコンパイル時の警告はありません。
| 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 |
これが重要な理由: 医療の心電図波形では、単一サンプルのスパイクが不整脈を示すかもしれません。振動解析では、狭い共振ピークが数サンプルしか占めないかもしれません。半導体試験では、短い逸脱がマイクロ秒しか続かないかもしれません。リサンプリングはこれらすべてを隠します。無損失レンダリングはこれらを見せます。
ゼロコピー データロード: メモリが2倍になる理由（ならない理由）
すべてのチャートライブラリはあなたのデータへのアクセスを必要とします。問題は、既存の配列を読むのか、それともすべてを自前の内部ストレージへコピーするのかです。この違いがメモリ消費、ロード時間、ガベージコレクション負荷を決めます — 3つの要素は規模が大きくなるほど劇的に複合します。
ProEssentials の UseDataAtLocation() は既存配列へのポインタを保存します。チャートが自前のコピーを確保することはありません。つまり1億個の float 値のロードは実質ゼロ時間（ポインタ代入）かつゼロ追加メモリです。ソース配列を変更し、ReinitializeResetImage() を呼べば、チャートは即座に更新後のデータからレンダリングします。
| 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 |
1億ポイントの float[] 配列（400MB）の場合、総メモリフットプリントは: ProEssentials: 400MB（あなたの配列のみ）。SciChart: 1,200MB（あなたの配列 + 800MB の内部 double[] コピー）。Syncfusion: 2,800MB以上（あなたの配列 + 2.4GB のポイントごとのオブジェクトラッパー）。1億ポイントでは、ゼロコピーは最適化ではありません — 動くアプリケーションと OutOfMemoryException でクラッシュするアプリケーションの分かれ目です。
リアルタイム ストリーミング性能
リアルタイム チャートは静的ベンチマークが見落とす次元を加えます: メモリ増加なしの、時間にわたる持続スループットです。毎秒10,000サンプルを8時間ストリーミングするアプリケーションは2億8,800万データポイントを生成します。チャートは新データを追加し、旧データを破棄し、更新をレンダリングしなければなりません — メモリをリークさせず、GC 負荷を蓄積させずに。
ProEssentials はローリングウィンドウをネイティブに処理する内蔵サーキュラーバッファ（PeData.CircularBuffers = true）を提供します。新データは AppendYData() で追加され、旧データは末尾から落ち、バッファは決して成長しません。複数の追加を1回のレンダリングへまとめる PrepareImages と組み合わせれば、効率的なパイプラインができます: 任意のスレッドでデータを収集し、バッチし、一度レンダリングする。
SciChart も DataSeries に FIFO（先入れ先出し）モードを提供し、同様のローリング動作を実現します。違いは、SciChart の連続レンダーループがデータレートに関係なく毎秒60回チャートを再描画することです。計測器が毎秒10回更新を生成するなら、SciChart は各更新の間に50の冗長なフレームをレンダリングします。ProEssentials は正確に10フレーム — データ更新ごとに1フレーム — をレンダリングし、残りの時間 GPU はアイドルです。
| 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 |
あなたのアプリケーションに合うアーキテクチャは?
すべてのシナリオに最適な単一のアーキテクチャはありません。アプリケーションが実際に必要とするものに基づく、率直なガイドです:
| 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 |
| WinUI 3 application needing performance | ProEssentials — the only native WinUI engine | Syncfusion and DevExpress draw WinUI charts through managed XAML; ProEssentials brings the same GPU compute-shader engine to WinUI 3 |
| 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 |
パフォーマンスの結論
ProEssentials の GPU Compute Shader、オンデマンド レンダリング、無損失のデータ忠実度、ゼロコピー データロードの組み合わせは、WPF チャートライブラリの中でアーキテクチャ的に唯一無二です。4つすべてを同時に達成するライブラリは他にありません。SciChart は GPU の速度を提供しますが、連続的な電力消費とデータのリサンプリングを伴います。LightningChart は無損失レンダリングを提供しますが、連続的な電力消費と MVVM を壊す API 制約を伴います。Syncfusion と DevExpress は簡単な統合を提供しますが、性能上限は低めです — Syncfusion は約1,600万ポイントでメモリ不足エラーに達し、DevExpress はリサンプリングを有効にすれば約5,000万まで押し上げられますが、極端なメモリコストを払います。
科学、エンジニアリング、医療、産業のほか、大規模データセット、データの忠実性、電力効率が重要となるあらゆるアプリケーションにおいて、ProEssentials のレンダリングアーキテクチャは、WPF チャートコンポーネントとして利用できる最も強力な技術基盤です。この同じネイティブエンジンとアーキテクチャが、いまや ProEssentials の WinUI 3 インターフェイスも駆動しており、高性能な WinUI 3 チャート作成において唯一のネイティブエンジンによる選択肢となっています。
パフォーマンスについて質問がありますか?
ProEssentials のサポートは無料・無制限で、レンダリングエンジンを作った開発者が直接提供します。GPU アーキテクチャ、データロード、リアルタイム性能について何でもお尋ねください。
ProEssentials チームに問い合わせる →私たちの使命
御社とエンドユーザーに最も簡単で最もプロフェッショナルな価値を提供することで、お客様の成功を最優先目標とします。
私たちはエンジニアです
ProEssentials は、自らのチャートコンポーネントを必要としたプロの電気エンジニアから生まれました。ProEssentials を使う一流エンジニアリング企業の長いリストに加わってください。
ありがとうございます
ProEssentials のお客様であることに感謝するとともに、ProEssentials チャートエンジンをご検討いただきありがとうございます。