1億ポイント プロット WPF パフォーマンス ガイド

WPF のラインチャートに100,000,000データポイントをどう表示しますか? 答えは、どのチャートライブラリを使うかに完全に依存します。15行のコードとメモリ オーバーヘッドゼロでこなすものもあれば、特殊な系列タイプを必要としデータ忠実度を犠牲にするものもあります。そして、そもそもまったくできないものもあります。

この記事は、5つの主要 WPF チャートライブラリ — ProEssentials、SciChart、LightningChart、Syncfusion、DevExpress — すべてについて、同じ1億個の float 値を単一系列のラインチャートへプロットする、完全な動作する C# コードを提供します。あらゆる側面を比較します: コード行数、メモリ消費、レンダリング時間、データ忠実度、そして各ライブラリが舞台裏であなたのデータに実際何をしているか。

「plot millions of points WPF」や「WPF チャート パフォーマンス」と検索してきた方へ — これがコードレベルでの具体的な答えです。

ご自身でお試しください: ProEssentials のインストールには GigaPrime2D というデモが含まれます（完全なサンプルプロジェクト ソースコード付き)。このデモは1億ポイントを連続的にプロットします — 更新のたびに1億個すべての値を変更しながら。コードは意図的に最小限にしてあり、誰でも競合ライブラリを差し込んで、1億ポイントでの動作する並列比較を組み立てられます。

Building on WinUI 3? See the WinUI edition of this 100M-point comparison

テスト: 100,000,000個の float 値

すべてのライブラリが同じテストを受けます: ランダムノイズ付きの正弦波を表す1億個の連続 float 値 — センサーデータ、信号処理、科学計測に典型的なパターン — から単一系列のラインチャートをレンダリングします。問題はチャートが美しく見えるかではありません — ライブラリがそもそもデータを扱えるか、そしてそのためにメモリ・時間・忠実度で何を支払うかです。

以下に、各ライブラリの完全な C# コードを、各ステップであなたのデータに何が起こるかの注釈付きで示します。2つの点に注目してください: ライブラリがデータをどう受け取るか（コピーかポインタか)、そしてどうレンダリングするか（全ポイントかリサンプリングされたサブセットか）。

ライブラリ1: ProEssentials — ゼロコピー + GPU コンピュートシェーダー

ProEssentials は UseDataAtLocation() を使い、チャートを既存の float 配列へ直接向けます。コピーなし、変換なし、複製なし。チャートのネイティブ DLL はあなたのメモリへのポインタを保持し、レンダリング中にそれを読みます。ComputeShader = true と組み合わせると、GPU のコンピュートシェーダーが潜在的に2,000以上のシェーダーコアでチャート画像を構築します — CPU は1億個の値を一度も反復しません。

// 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();

鍵となる行は UseDataAtLocation(yData, yData.Length) です。これはコピー操作ではありません — ポインタの代入です。チャートはあなたの配列をその場で読みます。Filter2D3D = true にすると、ProEssentials はレンダリング パイプラインに前段の GPU コンピュートシェーダーを挿入し、最終レンダリング シェーダーが走る前にロスレスの min/max フィルタリングを行います。SciChart や DevExpress が使う攻撃的なビューポート幅リサンプリング — 1億ポイントをわずか数千まで削減し得る — と異なり、ProEssentials のフィルターは意図的に保守的です: フィルタリング後も系列は常に最低50万ポイントを保持します。フィルタリング シェーダーとレンダリング シェーダーの両方が GPU 上でマイクロ秒単位で実行されるなら、必要以上にデータを捨てる理由がないからです。結果は、信号のすべてのピーク、谷、過渡現象を保存するロスレスな表現です。

Force3dxVerticeRebuild と Force3dxNewColors のフラグは、Direct3D エンジンに、頂点データと色データをソース配列から再構築するよう伝えます。後で yData の値を変更し、ReinitializeResetImage() を呼ぶ前にこれらのフラグを再度設定すれば、チャートは即座に変更を反映します — 同じメモリを読んでいるからです。セットアップ全体で15行。特殊な系列タイプはありません — 100ポイントを扱うのと同じ Pesgo（Scientific Graph Object）が1億も扱います。ProEssentials 自身の例115は、5系列にわたって2,000万ポイント（合計1億）をプロットし、汗ひとつかかずにインタラクティブな速度でレンダリングします — 系列あたり2,000万など、コンピュートシェーダー パイプラインにとっては何でもないのです。

ライブラリ2: SciChart — 配列コピー + リサンプリング

SciChart は1億ポイントを表示できますが、その道のりには2つの大きなトレードオフがあります。第一に、dataSeries.Append() は1億個すべての値を SciChart の内部ストレージへ double[] としてコピーします — float(4バイト)から double(8バイト)へ、メモリが倍増します。第二に、SciChart のレンダリング パイプラインは、データをビューポート幅の約2倍（1920ピクセルのディスプレイでおよそ3,840ポイント）までダウンサンプリングします。

// 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);

SciChart で1億ポイントを現実的にするのが ResamplingMode.Auto 設定です。これがないと、GPU パイプラインは1億データポイント分の頂点バッファを処理しなければなりません — それは SciChart のゲームエンジン アーキテクチャの動き方ではありません。代わりに、CPU 側のリサンプラーが代表サブセットを選び（ピクセルビンごとの min/max を使用)、そのサブセットだけが GPU へ送られてレンダリングされます。

つまり SciChart は1億のうちおよそ3,840ポイント — データの約0.004% — をレンダリングしています。全体を引いて見る視覚的概観としては、これで十分なことも多いでしょう。しかし、10時間の記録のうち1秒の窓へズームインすると、リサンプラーは該当範囲を CPU で再スキャンして新しい代表サブセットを作ります。元の1億個の値は、SciChart の内部 double[] 配列に約800 MB を消費しながら、オンデマンドのリサンプリングを待って居座り続けます。

ライブラリ3: LightningChart — 配列コピー + 特殊系列

LightningChart は1億ポイントを扱えますが、それは SampleDataSeries — 固定間隔（均一サンプリング）データ専用に設計された特殊な系列タイプ — を通じてのみです。標準の系列タイプ（PointLineSeries、FreeformPointLineSeries）はこのスケールを扱えません。データは AddSamples(float[]) メソッドで内部バッファへコピーされ、LightningChart の DirectX 即時モードレンダラーがそれを処理します。新しいバリアントの SampleDataBlockSeries（v10.1 以降）は、ストリーミング/スイープのシナリオでさらに良い性能を提供します。

// 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.

決定的な制限: 最高の性能には、LightningChart は Non-Bindable エディションを必要とします。LightningChart の WPF 製品は Bindable と Non-Bindable のエディションで出荷されます — Non-Bindable エディションは高速でマルチスレッドをサポートしますが、WPF の MVVM データバインディング基盤を犠牲にします。アプリケーションが WPF のデータバインディング パターンを使っているなら（現代の WPF アプリの大半がそうであるように)、性能とアーキテクチャ互換性のトレードオフに直面します。

LightningChart は DirectX パイプラインを通じて1億ポイントすべてをレンダリングします（ロスレス)。トレードオフは、配列コピー（約400 MB の追加メモリ)、必須の特殊系列タイプ、Non-Bindable エディションの推奨、そしてチャートがアイドルでも GPU を稼働させ続ける LightningChart の連続レンダリング ループです。

ライブラリ4: Syncfusion — ポイントごとオブジェクトのアーキテクチャ

Syncfusion の WPF チャートはポイントごとオブジェクトのデータモデルを使います。各データ値をクラスのインスタンス（通常 X と Y のプロパティ付き）でラップし、IEnumerable コレクションへ追加しなければなりません。1億ポイントでは、1億個の .NET オブジェクトを作ることになります — それぞれが24バイトのオブジェクトヘッダー（64ビット環境)、2つの double プロパティ（16バイト)、パディング付きです。合計: 元の400 MB のソースデータに加えて、約2.4 GB のマネージドヒープ割り当てです。

// 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);

実際には、この割り当てループには数分かかり、完了前に OutOfMemoryException を引き起こすのが通例です — 特に32ビットプロセスやメモリの限られたシステムでは。Syncfusion の応答性を保てる実用上限は、FastLineBitmapSeries を使っておよそ100万ポイントです。このライブラリは中程度のデータ量のビジネス ダッシュボードには適していますが、1億ポイントの科学/エンジニアリング シナリオのためには設計されていません。

ライブラリ5: DevExpress — ポイントごとオブジェクト + リサンプリング

DevExpress の WPF は、大規模データの処理に LineSeries2D と AllowResample = true を使います。注意: 性能の議論でよく言及される DevExpress の SwiftPlotSeriesView は WinForms 専用で、WPF のチャートコントロールには存在しません。WPF では、AllowResample(v20.1 で導入)がビューポート対応のリサンプリングを有効にし、レンダリングを可視範囲に限定します。DevExpress 自身のブログ記事は、このアプローチを5,000万ポイントまでテストしました。ただし、データモデルは依然としてポイントごとオブジェクトです — 1億では、レンダリングを始める前に約2.4 GB の DataPoint オブジェクトを割り当てなければなりません。

// 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.

1億ポイントで1億個の .NET オブジェクトを作るのは、十分な RAM を積んだ64ビットシステムでぎりぎり可能です(ソースデータ込みで合計約2.8 GB)。割り当てが成功すれば、AllowResample はビューポートのサブセットだけをレンダリングします — SciChart のリサンプリング アプローチに似ています。しかし、SciChart（生の double をフラット配列に保存）と異なり、DevExpress は24バイトヘッダー付きのラップ済みオブジェクトを保存するため、ポイントあたりのメモリコストはおよそ6倍高くなります。DevExpress のテスト済み上限は5,000万です。1億は、同社の公開ベンチマークにおいては未踏の領域です。

リサンプリングが奪うもの

SciChart と DevExpress は、現実的なエンジニアリング上のトレードオフとしてリサンプリングを使います: すべてをレンダリングするのではなく、データの代表サブセットを表示するのです。幅1920ピクセルのチャートには、最大1,920の水平ピクセル列しかありません。1億ポイントを1,920列にレンダリングするということは、約52,083ポイントが各ピクセルを奪い合うことです。SciChart のリサンプラーはビンごとに最小値と最大値を選び、約3,840の代表ポイントを生成します — データの視覚的エンベロープを保つには十分です。DevExpress の AllowResample も同様のビューポート限定アプローチを使います。

概観表示（「データセット全体を見せて」)では、これはロスレス レンダリングと視覚的に区別がつかないことも多いでしょう。問題は精度が重要になるときに現れます: 科学データの異常検知、信号処理での正確なピーク特定、あるいはすべてのサンプルが検証可能でなければならない医療・製薬記録の規制遵守。1サンプルの過渡現象がポイント47,291,033で発生した場合、ピクセル列あたり52,083ポイントを2つの代表へ削減するリサンプラーは、その特定のポイントを選ぶかもしれないし、選ばないかもしれません。

ProEssentials は Filter2D3D GPU コンピュートシェーダーで根本的に異なるアプローチを取ります。1億ポイントを画面幅分のひと握りの代表へ攻撃的に削減するのではなく、Filter2D3D シェーダーは GPU 上で保守的かつロスレスな min/max 前段フィルターパスを実行します — そして結果は常に最低50万ポイントを保持します。論理はシンプルです: フィルタリング シェーダーと最終レンダリング シェーダーの両方が GPU 上でマイクロ秒単位で実行されるなら、データの破棄に攻撃的になる理由はありません。フィルターは各フィルタリング窓内のすべての最小値と最大値を保存するため、過渡現象、スパイク、異常は決して捨てられません。本質的にロスレスです — レンダリングされた画像は、完全なデータセットから生成されたものと同一です。LightningChart も DirectX パイプラインを通じてロスレスにレンダリングしますが、配列コピー（約400 MB のオーバーヘッド）と連続レンダリング ループを必要とします。ProEssentials は同じロスレスの結果を、メモリ オーバーヘッドゼロとオンデマンド レンダリングで達成します。

1億ポイントをプロットするのにかかるコスト

1億ポイントの描画を試みられるライブラリは 4 つありますが、その規模でテスト済みなのは 3 つだけです。以下は、それぞれのコストをライセンスモデルも含めて示したものです。というのも、1億ポイントを扱えるものの 5 年間で $288,750 かかるライブラリと、一度きりの $11,999 で済むライブラリとでは、まったく別の話だからです。

ProEssentials は、ゼロコピー データ読み込み、ロスレスな GPU コンピュートシェーダー フィルタリング、オンデマンド フレームモデル、永続ライセンス、無料無制限サポートを併せ持つ唯一のライブラリです — このデータセットを扱える他のライブラリのサブスクリプション費用のほんの一部の価格で。

結論

WPF で1億ポイントを試みられるライブラリは4つです。メモリ オーバーヘッドゼロ、ロスレスな GPU フィルタリング、オンデマンド レンダリングで — 15行のコードで — それをやるのは ProEssentials だけです。SciChart はリサンプリングでこのスケールを扱います（高速だがロッシー)。LightningChart は特殊系列タイプで扱います（ロスレスだが、配列コピー、Non-Bindable エディション、連続 GPU が必要)。DevExpress は AllowResample で試みられます（リサンプリング、ただし2.4 GB のオブジェクト オーバーヘッド付き — 自社ベンチマークでは5,000万超は未テスト)。

Syncfusion はこのシナリオのために設計されていません。ポイントごとオブジェクトのアーキテクチャは1億をはるかに下回るところでメモリ限界に達し、自社フォーラムには1,600万ポイントでのメモリ不足クラッシュが文書化されています。DevExpress も同じポイントごとオブジェクトのボトルネックに直面しますが、ビューポート リサンプリングで部分的に緩和します — 最初の割り当てが成功すれば。どちらのライブラリも100万ポイント未満のビジネス ダッシュボードでは優秀で、その幅広い UI コントロール スイートは専用チャートライブラリにはない価値を提供します。

あなたのアプリケーションが1億ポイントの表示を必要とするなら — センサーデータ、信号処理、科学計測、産業モニタリング — 上のコードが各ライブラリの要求を正確に示しています。コピーして、実行して、計測してください。数字が自ら語ります。

GPU アーキテクチャの深掘り

コンピュートシェーダー、オンデマンド レンダリング、ゼロコピー データ読み込みの内部の仕組み。

AI コード支援

pe_query.py はすべてのプロパティパスをコンパイル済み DLL バイナリと照合検証します — 幻覚 API 呼び出しなし。

価格とサポートの比較

5ライブラリ全体での開発者10人の5年間 TCO。永続対サブスクリプション ライセンス。

出典と参考資料

この記事のすべての競合コード例は、公式ドキュメント、公開 GitHub リポジトリ、ベンダー フォーラム投稿から構成されています。API 名、メソッド シグネチャ、アーキテクチャに関する主張は、以下の出典と照合して検証済みです。リンクは2026年2月時点のものです。