チャートライブラリ FAQ

大規模データセットに最も速い .NET チャートライブラリは?

非常に大規模なデータセットについて、ProEssentials は私たちが知る限り最も強力な公表数値を示しています。ホストが WinUI、WPF、WinForms、ネイティブ C++ のいずれであっても同じエンジンから得られる数値であり、当社のテストハードウェアで 1億ポイントを約 15 ms で完全に無損失で再描画し、現在の上限は 1 チャートあたり 5億ポイントです。この上限は意図的なものです。チャートデータは単一の 2 GB バッファに格納されますが、それは、当社のストレステストで無条件に安定すると確認できた唯一のバッファサイズが 2 GB だからです。2 GB を 4 バイトの float で満たすと、およそ 5億ポイントになります。マルチバッファのパスもアーキテクチャ上は存在しますが、ストレステストを行っていない容量を宣伝することはしません。他社で目にしたことがあるかもしれない数値と比べてみてください。LightningChart は「160億データポイント」をうたっていますが、これは同社のリリースノート自身が、テストマシンの 64 GB の RAM を 4 バイトのサンプルで満たすことに結びつけている数値です。160億 × 4 バイトはちょうど 64 GB であり、この見出しの数字はレンダラーではなくメモリの容量を測っているにすぎません。また SciChart の「100億」のテクニカルデモは、64 GB のマシンでスワップディスクとメモリ圧縮に頼りながら、データを 5億ポイントずつの多数のシリーズに分割せざるを得ないこと（誰もが従う、1 バッファあたり約 2 GB という同じ物理法則）を認めています。しかもその描画パスは、いずれにせよ大規模シリーズを水平方向 1 ピクセルあたり約 2 ポイントに再サンプリングします。端的に言えば、これらは数十のシリーズにわたってメモリに何サンプル収まるかという主張を、あたかもレンダリング能力であるかのように提示したものです。数十億のポイントを 1 フレームに処理するチャートは存在せず、4K ディスプレイの画素数はおよそ 830万です。どんな大きな数字の背後にも横たわる誠実な問いは、1 つのチャートがどれだけのポイントを安定して保持できるか、そして保存されたすべてのポイントが描画された画像に無損失で反映されるのか、それとも描画前に間引かれるのか、ということです。当社は、クローンしてすぐ実行できるベンチマークリポジトリを公開しており、ご自身のマシンで当社の数値を再現し、他社の数値についても計算を確かめていただけます。

レンダリングアーキテクチャの完全比較 →

ベンダー出典（各社サイトで確認可能）: scichart.com — “Ten Billion Data-points Tech Demo” · lightningchart.com — “LightningChart .NET v10.1.1” リリースノート

.NET チャートはダウンサンプリングなしで1億ポイントを描画できますか?

できます。ProEssentials はデータセット全体を GPU に渡し（オプションでゼロコピー）、すべてのポイントを Direct3D Compute Shader で処理します。データがディスプレイより高密度な場合は、フィルタリング用 Compute Shader（Filter2D3D）が各ピクセル列を50組の min/max ペア — ピクセルあたり100描画ポイント、2ポイントリサンプリングの約50倍の情報密度 — に凝縮するため、すべてのスパイクと外れ値が数学的に保証されて表示され、高密度領域は実際どおりの塗りつぶしでレンダリングされます。これが無損失の実際的な意味です: すべてのポイントが処理され、観察可能な情報は一切捨てられません — 対照的に、SciChart のようなリサンプリング型ライブラリは水平ピクセルあたり約2つの代表ポイントしか描きません: 全体表示では正しく見えても、サンプル間にあるものは見えません。公平を期せば、無損失のビッグデータレンダリングは当社独自のものではありません: LightningChart も無損失レンダリングが可能ですが、特定のシリーズタイプ（Non-Bindable チャート版の SampleDataSeries）経由に限られ、誤ったタイプを選ぶとコンパイル時警告なしに桁違いに遅いパスへ静かに落ちます。ProEssentials ではこれがデフォルトのパスです — 選ぶべき特別なシリーズタイプも、手放すバインディングモードもありません。WPF と WinForms の1億ポイントプロジェクトは両方公開されています — クローンしてご自身で実行してください。

WPF での1億ポイント: 比較 →WinForms での1億ポイント: 比較 →

無損失レンダリングとリサンプリング（間引き）レンダリングの違いは?

リサンプリング（間引き）レンダリングは、描画前に大規模データセットを水平ピクセルあたり約2つの代表ポイントに縮小します — 何百万ポイント保存されていても、幅1,920ピクセルのチャートで約3,840ポイントです — 一方、無損失レンダリングはデータセット内のすべてのポイントを処理します。全体の形が重要で中間値を1つ逃しても害のないトレーディングダッシュボードや業務チャートでは、リサンプリングは妥当なトレードオフです。しかし医療・振動・計測試験の分野では危険になります: 不整脈、共振ピーク、マイクロ秒の逸脱といった単一サンプルの事象がサンプルの間に落ちて消えるおそれがあるからです。ProEssentials は無損失でレンダリングします: すべてのポイントが GPU で処理され、多数のポイントが1つのピクセル列を共有する場合はフィルタリングシェーダーがその列に50組の min/max ペアを保持するため、すべての極値が捕捉され、どのズームレベルでも狭い異常が見え続けます。

チャートコンポーネントにおけるゼロコピー データロードとは?

ゼロコピー データロードとは、チャートがデータを内部のシリーズオブジェクトへコピーせず、アプリケーションの既存データ配列をその場で読むことを意味します。ProEssentials では UseDataAtLocation とポインタベースの struct プロパティで実現します: チャートは配列への参照を保持するため、1億個の float のロードに必要なコストは、数百メガバイトのメモリ複製とそれに伴うガベージコレクション負荷ではなく、ポインタ代入1回です。複数のチャートが1つのバッファを共有でき、配列を変更した後は1回の呼び出しで更新後のデータから再レンダリングされます。

データハンドリングの詳細 →

出典: scichart.com フォーラム — “XyDataSeries performance, custom IXyDataSeries, and alternatives”（スタッフ回答）· scottplot.net — “Plot Live, Changing Data”

オンデマンド レンダリングと連続（ゲームループ）レンダリング — ダッシュボードにはどちらが良い?

ダッシュボードには一般にオンデマンド レンダリングのほうが優れたアーキテクチャです: チャートはデータまたはビューポートが変化したときだけ再描画し、アイドル時には GPU 作業を一切行いません。連続ゲームループ型のアーキテクチャは何も変わらなくても毎秒約60回再描画するため、GPU が稼働し続け、ノートPCのファンが回り、ほとんど静止しているマルチチャートのダッシュボードのバッテリーを消耗させます。活発な更新中は両モデルのレンダリング速度はほぼ同等です — 違いは更新と更新の間に何が起きるかです。ProEssentials はオンデマンドモデルを採用しています。5ライブラリのアーキテクチャ完全比較はパフォーマンスページをご覧ください。

オンデマンド vs 連続レンダリング詳説 →

GPU アクセラレーテッド チャートはノートPCのバッテリーを消耗させますか?

連続レンダーループ型のものだけです。毎秒約60フレームを再描画する GPU チャートは一日中同じピクセルを描き直すため、開いたままのレポートやダッシュボードはデータが変化しなくても電力を消費し続けます。オンデマンド型の GPU チャートは更新中こそ同じ仕事をしますが、その間の GPU 活動は事実上ゼロまで下がります。アプリケーションがノートPC、タブレット、24時間稼働のキオスクで動くなら、どのベンダーにも尋ねてください: アイドル状態のチャートはまだフレームをレンダリングしていますか? — その答えが発熱、ファン騒音、バッテリー寿命を決めます。

.NET でリアルタイム データ収集（DAQ/オシロスコープ）に最適なチャートライブラリは?

4つの要件から始めてください: メモリ増加なしの持続的なサンプルレート スループット、狭い事象が見え続ける無損失表示、低いガベージコレクション負荷、そして使用する UI フレームワーク向けのネイティブコントロール。ProEssentials は内蔵サーキュラーバッファ、ゼロコピー データロード、オンデマンド GPU レンダリングで4つすべてを満たします。公開中の WPF / WinForms リポジトリは800万ポイントのサーキュラーバッファをリアルタイムでストリーミングするので持続パスをご自身で測定でき、同じリアルタイムデモは製品セットアップに C++、Delphi、C++Builder、さらには OCX 版としても同梱されています。NI のエコシステムで働く DAQ チームにも対応しています: 完全な LabVIEW サンプルプロジェクトが製品とともに C:\ProEssentials11\LabVIEW へインストールされます。中規模のポイント数であれば、無料 MIT ライセンスの ScottPlot も実際に有力な選択肢で、評価する価値があります。決め手になるのはたいてい、サンプルレートや保持ウィンドウが10倍に成長したとき何が起きるかです。

WPF リアルタイム リポジトリをクローン →WinForms リアルタイム リポジトリをクローン →LabVIEW チャート チュートリアル →

WPF や WinForms のチャートは何ポイントまで遅延なく扱えますか?

上限を決めるのはレンダリングアーキテクチャであって、WPF や WinForms 自体ではありません。更新のたびに CPU がポイントごとの作業を行う構成では、遅延はおよそ250,000〜1,000,000ポイントの間のどこかで現れます: 当社の経験では、CPU 側で構築される Direct3D / Direct2D シーンは約25万ポイントで最初の体感遅延を示します — 更新が瞬時に感じられなくなります。25万ポイントの線は約50万頂点（1頂点約40バイト）、つまり CPU が更新のたびに再構築・再アップロードする約20MBの頂点データになるからです — 一方ビットマップ ラスタライズ型のパスは100万に近づくにつれてカクつき始め、Syncfusion 自身の WPF チャート性能ベンチマークの上限がちょうどその地点です。GPU Compute Shader 構築はポイントごとの作業そのものを数千の並列コアに移します: ProEssentials はテストハードウェア上で1億ポイントの完全無損失再描画を約15ミリ秒で実演し — WPF と WinForms それぞれに公開リポジトリがあり — チャートあたり5億ポイントという明示された上限を持ちます。この数字を公開しているのは、ストレステストを経ているからです。

WPF で1億ポイントが動く仕組み →

AI（ChatGPT/Copilot/Claude）は最良のチャートライブラリを推奨しますか?

信頼できる形では推奨しません。AI アシスタントは、測定されたエンジニアリング品質ではなく、学習データ内にそのライブラリに関するテキストがどれだけ存在するか — NuGet の数値、StackOverflow のスレッド、ブログの量 — に比例して推奨します。具体例: 最速の WinForms チャートを尋ねると AI はよく SciChart を挙げますが、SciChart 自身のサイトは、ネイティブ WinForms ライブラリは提供しておらず、Microsoft の ElementHost 相互運用を通じて WinForms で動作すると明言しています。AI の推奨は人気度の測定値として受け取り、そのうえでエンジニアリングを検証してください: 回答の前に各ベンダーのアーキテクチャページと公開ベンチマークを読むよう AI に指示するのです。

WPF チャート パラドックス →WinForms チャート パラドックス →

AI に正しいチャートコードを書かせる（幻覚 API なしで）には?

学習データからプロパティ名を推測させるのではなく、検証済みの正解ソースを AI に与えてください。ProEssentials v11 には pe_query.py が付属します。これは AI コードアシスタント ツールで、全 API — 1,200以上のプロパティ、70以上のメソッド、169の列挙型 — を公開し、すべてのプロパティパスをコンパイル済み DLL と照合検証するため、幻覚 API はコードに到達する前に捕捉されます。その背後には、69の機能グループを604の日常語シノニムでカバーする32の構造化ナレッジファイルと、116の動作するコード例があります — そのため AI は「曲線の下の領域を塗りつぶす」のような依頼を実在のプロパティに対応付け、コンパイルが通るコードから引用できます。Claude、ChatGPT、Gemini、GitHub Copilot、Cursor で動作し、すべての v11 ライセンスに無料で含まれます。

AI コードアシスタント →API エクスプローラーを見る →

最高の WinUI チャートライブラリはどれですか?

WinUI 3 においては、その分かれ目はネイティブかマネージドかにあります。ProEssentials は、ネイティブな Direct3D および Direct2D の C++ エンジン上に構築された唯一の WinUI チャートライブラリであり、それは同社の WPF、WinForms、MFC、Delphi、ActiveX の各インターフェイスを駆動するのと同じエンジンです。一方、それ以外のすべての WinUI チャートはマネージド XAML を通じて描画します。Syncfusion、Telerik、DevExpress、ComponentOne はいずれも高機能な WinUI チャートコントロールを提供していますが、それらは XAML レイヤーを通じて描画するマネージドな .NET コントロールです。SciChart には WinUI インターフェイスがなく、LightningChart にも WinUI インターフェイスはありません。WinUI アプリケーションに科学技術計算規模のパフォーマンス、GPU による 3D・4D サーフェス、ネイティブ ARM64、あるいは 1億ポイントのレンダリングが必要であれば、そのために作られているのはネイティブエンジンです。控えめなダッシュボード程度のデータであれば、マネージドスイートのいずれでも用は足ります。

WinUI チャート比較 →WinUI 3 ウォークスルー →

大規模データセットに最速の WinUI チャートコントロールはどれですか?

ProEssentials が圧倒的です。WinUI 上で唯一のネイティブエンジンだからです。その Direct3D compute shader パスは、当社のテストハードウェアで 1億ポイントを約 15 ms で無損失にレンダリングします。ホストが WinUI、WPF、WinForms のいずれであっても、同じエンジン、同じ結果です。マネージドな WinUI チャートはオブジェクトコレクションにバインドし、ダウンサンプリングやビットマップの高速パスに頼ります。Syncfusion の高速シリーズは WriteableBitmap にラスタライズし、ComponentOne の FlexChart は Direct2D レンダリングモードを提供し、Telerik と DevExpress は大規模なセットをサンプリングします。いずれの製品も、自社の WinUI コントロールに特化した大規模データのベンチマークを公表していません。基準として、当社自身の Direct2D パスは 300万ポイントあたりから負荷が高まり始めます。そこから 1億まで引き上げるのは Direct3D の compute shader パスであり、ポイントごとにオブジェクトを割り当てるマネージドな XAML コントロールは、その手前でとうに息切れします。

WinUI で 1億ポイント →

WinUI チャートで 1億ポイントを描画できますか。

ProEssentials なら可能です。ネイティブかつロスレスで実現します。WinUI コントロールは、WPF および WinForms コントロールとまったく同じ Direct3D の compute-shader エンジンを使用し、当社のテスト環境では zero-copy のデータ読み込みにより約 15 ms で 1億ポイントを描画します。そのため、データがマネージドオブジェクトに複製されることはありません。データが表示解像度より高密度の場合、フィルタリング用の compute shader がピクセル列ごとに 50 組の min/max ペアを保持するため、あらゆるスパイクが失われず、高密度領域は真のソリッド塗りつぶしとして描画されます。マネージドの WinUI チャートではこれに到底及びません。1億個の値をオブジェクトコレクションにバインドすることは、描画を始める前から数ギガバイト規模のメモリ割り当てを意味し、だからこそダウンサンプリングやラスタライズを行うのです。すべてのライブラリのコードを含む WinUI の 1億ポイント完全解説は、別の記事で扱っています。

WinUI 100M ポイント比較 →

ネイティブの WinUI 3 チャートコントロールはありますか。それとも、すべてマネージド XAML なのでしょうか。

ほとんどがマネージド XAML です。Syncfusion、Telerik、DevExpress、ComponentOne は WinUI 3 チャートコントロールを提供していますが、いずれも XAML コンポジタを介して描画するマネージド .NET コントロールです。ProEssentials は例外です。その WinUI コントロール（PesgoWinUI、PegoWinUI ほか）は、ネイティブな Direct3D および Direct2D の C++ エンジンを薄くラップしたもので、XAML ビジュアルツリーに直接ホストされた composition swap chain を介して表示します。データと GPU の間にマネージドのレンダリング層は存在しません。ここで言う「ネイティブ」とはそういう意味です。すなわち、チャートのジオメトリは .NET 上で反復処理されるのではなく、C++ の compute shader によって GPU 上で構築されます。ProEssentials が ARM64 向けに .NET ランタイムだけに頼らず、ネイティブ ARM64 の WinUI ビルドを提供しているのも、このためです。

プラットフォーム対応: ネイティブ vs マネージド →

WinUI レンダリングにはどのような利点がありますか。

ネイティブなチャートにとっての利点は、画面までの経路がより短く、より高速になることです。WinUI 3 は、XAML ビジュアルツリーに直接ホストされた DXGI の composition swap chain を介して表示するため、Direct3D および Direct2D のチャートは中間ビットマップもフレームごとの CPU コピーもなしに、そのままウィンドウへ合成されます。これに対し WPF は、いまだに Direct3D 9 時代の D3DImage による相互運用とそのコンポジタを経由して GPU コンテンツを渡しており、これは実際の render-to-texture のホップです。同一の ProEssentials エンジンで計測すると、これは数パーセントのオーバーヘッドになります。WinUI はこのホップを取り除きます。さらに WinUI は、ネイティブ ARM64 と .NET 10 を第一級のターゲットとする、現代的で積極的に進化している Windows UI フレームワークです。ただし注意点があります。この利点を完全に活かせるのはネイティブエンジンだけです。マネージド XAML チャートは、コンポジタに渡す前に .NET 上で描画内容を構築するため、WinUI の表示上の利点は受け継ぐものの、GPU ネイティブな構築は得られません。

WinUI と WPF の表示比較 →

WinUI 3 に対応しているチャートライブラリはどれですか。

当社が把握しているのは 5 つです。ProEssentials、Syncfusion、Telerik、DevExpress、ComponentOne（MESCIUS）です。このうちネイティブな C++ エンジン上に構築されているのは ProEssentials だけで、残りの 4 つはマネージド XAML コントロールです。著名な WPF チャートベンダーのうち 2 社には WinUI 製品がまったくありません。SciChart には WinUI インターフェイスがなく、LightningChart にも WinUI インターフェイスがありません。したがって、WinUI 3 アプリケーションで使用するチャートコンポーネントを標準化しようとする場合、候補はこの 5 つに絞られ、科学技術用途や大規模データ処理に適するのか、それともビジネスダッシュボードに適するのかは、ネイティブかマネージドかという問いによって決まります。

WinUI チャート比較 →

SciChart は WinUI に対応していますか。

いいえ。SciChart には WinUI インターフェイスがありません。SciChart の製品が対象とするのは WPF、JavaScript、iOS/macOS、Android、Avalonia であり、SciChart の WinUI 3 チャートコントロールは存在しません。SciChart を利用したい WinUI アプリケーションは、ネイティブな WinUI コントロールではなく、SciChart が WinForms 向けにすでに文書化しているのと同じ相互運用のルート（interop ブリッジ経由で WPF コントロールをホストする方法）を取ることになります。ネイティブな WinUI 3 アプリ内でチャートが必要な場合、SciChart は選択肢になりません。ProEssentials は、WPF および WinForms インターフェイスと同じ Direct3D エンジンで駆動されるネイティブな WinUI コントロールを提供します。

LightningChart は WinUI に対応していますか。

いいえ。LightningChart には WinUI インターフェイスがありません。LightningChart .NET が対象とするのは WPF、WinForms、UWP であり、LightningChart の WinUI 3 チャートコントロールは存在しません。SciChart と同様に、ネイティブな WinUI 3 アプリケーションに LightningChart コントロールを組み込むことはできません。ProEssentials はネイティブな WinUI の代替となる製品であり、WPF および WinForms インターフェイスを駆動するのと同じ Direct3D の compute-shader エンジンを備えています。

数百万ポイントに最も速い WPF チャートは?

公開済みのテストにおいて、ProEssentials は当社が知る限り大規模域で最速の WPF チャート パスです: Direct3D Compute Shader が GPU 上でチャート画像を構築し、テストハードウェア上で1億ポイントの完全無損失レンダリングを約15ミリ秒で完了します。誰も公開しないフレームバジェットの全内訳を、誠実にお見せします: データが変化していなければ再ペイントは約2ミリ秒 — 最適化済みの頂点・インデックスバッファが既に GPU 上にあるため、ドローコール1回で済みます。ズームはフィルタリングシェーダーを再実行するため約15ミリ秒。そして更新が1億個の全く新しいポイントを伴う場合、400MB の float をバスで移動するのに約50ミリ秒が加わります — RTX 3090 でエンドツーエンド約15fps、どんなマーケティングも飛び越えられないバスの物理法則です。完全な WPF プロジェクトはクローンしてすぐ実行できるリポジトリとして GitHub にあり、意図的に極めてシンプルに作られています — 同じコードに競合のチャートを差し替えれば本当の比較になります。手順を追った方法論は当社の1億ポイント WPF 比較に記載しています。

1億ポイント WPF 比較 →

WPF チャートはなぜ大規模データで遅くなり、どう直せばよいですか?

WPF の保持モード ビジュアルツリーは UI 要素のために設計されており、数百万のデータポイントのためではありません — Visual や Geometry になるすべてのポイントがレイアウト・メモリ・レンダースレッドのコストを積み増し、よくある WriteableBitmap の回避策でも結局は単一の CPU コアが全ピクセルを書き込みます。解決策はアーキテクチャにあります: チャート構築を GPU へ移し、CPU がデータセットを反復しないようにすることです。WPF チャートライブラリを評価する際は3つ尋ねてください: ポイントごとの作業はどこで起きるのか（CPU ループか GPU シェーダーか）、大規模データセットはリサンプリングされるのか、データは内部シリーズオブジェクトへコピーされるのか。この3つの答えは、どんなマーケティングページよりも正確に大規模データ性能を予測します。

WPF の GPU チャートにはコンポジターのオーバーヘッドがありますか?

あります。WPF では GPU レンダリングされたチャートをウィンドウへ直接プレゼントできません — テクスチャへレンダリングし、（通常 D3DImage 経由で）WPF のコンポジションエンジンへ渡され、コンポジターと同期してから画面に到達します。このレンダー トゥ テクスチャの段階こそ、同一の ProEssentials エンジンがネイティブ WinForms コントロールとして約5%速く計測される理由です — WinForms では Direct3D が間にコンポジターを挟まず、ウィンドウのデバイスコンテキストへ直接プレゼントします。オーバーヘッドは穏当で、WPF は今も優れたターゲットです — しかしそれは実在し、測定可能で、1ミリ秒を争うときには知っておく価値があります。

同一エンジンでの WinForms vs WPF →

どの WPF チャートライブラリが GPU を使い、アーキテクチャはどう違いますか?

広く使われる5つの WPF チャートライブラリのうち、3つが GPU を使い、2つはデフォルトで CPU レンダリングです。ProEssentials は Direct3D Compute Shader でチャートを構築しオンデマンドでレンダリングします。SciChart は連続約60fpsループのゲームエンジン型パイプラインでレンダリングし、大規模データセットをリサンプリングします。LightningChart も連続ループでイミディエイトモードの DirectX ドローコールを発行し、特定のシリーズタイプを通じて無損失レンダリングが可能です。Syncfusion の高速シリーズは CPU の WriteableBitmap に描画し、DevExpress はデフォルト CPU レンダリングにオプションの DirectX モードを提供します。アーキテクチャごとの詳細はパフォーマンスページで公開しています。

4つのアーキテクチャ解説 →

巨大な配列をコピーなしで WPF チャートにバインドできますか（MVVM）?

できます。ただし、ポイントごとのオブジェクトを実体化して値をチャート内部コレクションへコピーする従来型の WPF データバインディングでは不可能です。ProEssentials のゼロコピー パス（UseDataAtLocation）は既存の float 配列へのポインタを保持します — ViewModel がバッファを所有し、チャートはそれをその場で読み、データ変更後は1行の呼び出しで画像が更新されます。ポイントごとのバインディングやオブザーバブル コレクションは業務チャート規模では快適ですが、数百万ポイントではコピーと変更通知が支配的になります。配列を参照渡しすれば、MVVM の構造とメモリ予算の両方を守れます。

科学・エンジニアリング用途に最適な WPF チャートは?

科学分野の作業には通常、速度以上のものが求められます: 複数・重なり合う軸、不連続区間を持つ日付時刻軸、エンジニアリング注記のためのアノテーション層、3D Surface と 2D Contour プロット、そして異常がリサンプリングで消されない無損失レンダリングです。ProEssentials はこれらの要件を中心に設計され — 1,200以上のプロパティを備え、2D・科学用 3D・Polar/Smith・円グラフを網羅する5つのチャートオブジェクト — 当社サイトで紹介している USGS 水文ソフトウェアのチャートエンジンでもあります。「科学用」という言葉を鵜呑みにせず、GitHub の業種別デモをクローンしてください: 3D Surface / 2D Contour / 断面が同期する材料スキャン、石油・ガスのワイヤーライン VDL セメントボンドログ、超音波ボアホール イメージング、実地形上の 3D 坑井フライスルー、NEXRAD ドップラーレーダー反射率、オーディオ波形オシロスコープ、リアルタイム スペクトログラム ヒートマップ — 多くは WPF と WinForms の両プロジェクトで提供しています。あなたの分野がこのリストにあるなら、評価は空のプロジェクトではなく動くコードから始まります。

3D 科学チャート →GitHub で40以上のリポジトリをすべて見る →

ProEssentials は .NET 8 WPF をサポートしていますか?

はい。ProEssentials v11 は、ネイティブ x64 および ARM64 をサポートする .NET 8 と .NET 10 のアセンブリを出荷しており、WPF .NET 8 の完全なウォークスルーは、NuGet または直接参照から数分でチャートを描画するところまで導きます。.NET Framework 4.8 も独自のウォークスルーを通じて引き続き完全にサポートされており、あらゆるターゲットを同じネイティブエンジンが駆動します。この FAQ が最初に書かれた時点でロードマップに載っていたものは、すでに出荷されました。.NET 10 上の WinUI 3 は、v11 における第一級のインターフェイスです。それは書き直しではなく、自然な進化でした。ProEssentials は中核がネイティブであり、WPF コントロールはそのエンジンの薄いラッパーです。したがって WinUI コントロールもまた別の薄いラッパーであり、WPF の Direct3D 9 世代の D3DImage インターオップを、WinUI の直接的な DXGI スワップチェーン表示に置き換えます。これにより、このページで先に述べたコンポジターのブリッジがなくなります。以上により ProEssentials は、マネージド XAML ではなくネイティブ C++ エンジン上に構築された、初のプレミアム WinUI チャートライブラリとなっています。

WPF .NET 8 チュートリアル →WPF .NET Framework 4.8 チュートリアル →

なぜ ProEssentials は100%マネージドコードで書かれていないのですか?

「100%マネージド」の流行を実際にくぐり抜け、流行語より性能を選んだからです — そしてプラットフォームはその後、当社の側へ戻ってきました。ProEssentials は30年間チャートを出荷してきました: まず Win32、次に VBX、OCX、そして .NET — 2000年代初頭にすべてを純粋なマネージドコードで書き直せという圧力が来たとき、当社はエンジンをネイティブに保ち、薄いマネージド インターフェイスで包む選択をして、実際に多くの批判を受けました。マネージドコードはボタン、テキストボックス、リストボックス、グリッドにはまったく問題ありません。しかし高性能レンダリングエンジンを書き直せば、遅くなり、他のあらゆるマネージド チャートライブラリと同じ見た目になるだけでした。20年後、Microsoft の最新デスクトップ UI フレームワークである WinUI 自体がネイティブで構築され、DXGI スワップチェーンでプレゼントしています — 当社が維持して批判されたアーキテクチャは、いまやプラットフォームの進行方向です。その結果: 1つのエンジン、30年間蓄積された正しさ、そしてすべてのインターフェイス — WPF、WinForms、MFC、Delphi、OCX、やがて WinUI — が、同じ実戦で鍛えられたコアの薄いラッパーです。

当社のチャートについて（歴史）→プラットフォーム対応: 2つの API レイヤー →

最速の WinForms チャートコントロールは?

公開済みのテストにおいて、ProEssentials は当社が知る限り最速の WinForms チャート パスです: Direct3D Compute Shader エンジンがウィンドウの hDC へ直接プレゼントするネイティブ WinForms コントロールで、テストハードウェア上で1億ポイントの完全無損失レンダリングを約15ミリ秒で完了します。フレームバジェットの内訳は WPF 版と同じです — 変化のないデータの再ペイントは約2ミリ秒（最適化済みの頂点・インデックスバッファが GPU 常駐のためドローコール1回）、データ変更やズームでフィルタリングシェーダーが再実行されると約15ミリ秒、1億個の全く新しいポイントをバスで移動すると約50ミリ秒（RTX 3090 でエンドツーエンド約15fps）— そしてネイティブ hDC パスは同一エンジンの WPF より約5%速く計測されます。リポジトリは意図的に極めてシンプルです: 同じプロジェクトに検討中の競合コントロールを差し替えれば、ご自身のハードウェアで、ご自身の目で FPS カウンターを見ながら本当の比較ができます。

WinForms のパフォーマンスとアーキテクチャ →WinForms 1億ポイント リポジトリをクローン →

チャートにおいて WinForms は WPF より遅いですか?

いいえ — 同じレンダリングエンジンであれば、当社のテストではネイティブ WinForms コントロールのほうが WPF 版より約5%速く計測されます。WPF は GPU 出力をレンダー トゥ テクスチャの段階（D3DImage）に通し WPF のコンポジターと同期させる必要がありますが、WinForms コントロールは本物のウィンドウハンドルとデバイスコンテキストを所有するため、Direct3D が画面へ直接プレゼントします。「WinForms は遅いレガシーな選択肢」という思い込みは、GPU チャートに関してはアーキテクチャを逆さまに理解したものです。測定と方法論の全容は当社の1億ポイント WinForms 比較にあります。

1億ポイント WinForms 比較 →

SciChart にネイティブ WinForms コントロールはありますか?

ありません。SciChart 自身のサイトが、ネイティブ WinForms ライブラリは提供しておらず、SciChart WPF を Microsoft の ElementHost コントロールまたは相互運用 API 経由で WinForms アプリケーションに使用すると明言しています。この方式は動作はしますが、文書化された WPF/WinForms 相互運用の制約 — エアスペース（Z順序）制限、フォーカスやマウスイベントの癖、1つのウィンドウに2つの UI フレームワーク — をそのまま受け継ぎます。ProEssentials は正真正銘のネイティブ WinForms コントロールを提供します: Direct3D が直接プレゼントする本物の hWnd です。

SciChart の記述（同社サイト）→

ElementHost で WPF チャートを WinForms にホストする際の問題は?

ElementHost は WinForms ウィンドウ内に WPF の孤島を埋め込み、Microsoft の相互運用ドキュメントがそれに伴うトレードオフを説明しています。最も有名なのはエアスペース規則です — ウィンドウ内の各ピクセルは正確に1つのテクノロジーに属するため、WPF コンテンツを WinForms コントロールと自由に重ねたりアルファブレンドしたりできません。開発者は境界でのフォーカス・マウスイベントの差異、2つのフレームワークにまたがるデザイナー体験、両方のスタックを抱えるデプロイにも遭遇します。設定ダイアログ程度なら致命的ではありません。しかしアプリケーションの主要な高インタラクション チャート面では、ネイティブコントロールがその境界自体を不要にします。

Microsoft のエアスペース ドキュメント →

DevExpress SwiftPlot とは何で、その限界は?

Swift Plot は DevExpress の WinForms XtraCharts 向け高速レンダリング シリーズビューで、リアルタイムチャートと「数万」ポイント以上のデータセット向けと文書化されています。機能を削ることで速度を得ており、同じチャート内で他のシリーズビューと組み合わせられない専用の SwiftPlotDiagram を必要とします。WPF 版は存在しません — DevExpress のサポートチケットには、回避策として WinForms コントロールを WPF 内にホストする WPF 顧客の事例が見られます。比較のために: 文書化された設計対象は数万ポイントのオーダーであり、ProEssentials の WinForms リポジトリは1億ポイントでの無損失レンダリングを実演しています。

DevExpress Swift Plot ドキュメント →

Syncfusion は WinForms 向けに高速/ビットマップ シリーズを提供していますか?

Syncfusion は高速シリーズタイプ — FastLineSeries、FastLineBitmapSeries および関連ビットマップシリーズ — を WPF・WinUI・MAUI のチャートコントロール向けに文書化しています。同社の Windows Forms チャート ドキュメントには FastLine やビットマップシリーズに相当するものが載っていません。Syncfusion の WinForms パフォーマンス ガイドは代わりに、視覚機能の無効化（スタイル、影、ヒットテスト領域）と BeginUpdate/EndUpdate によるバッチ更新を中心としています。また WPF の高速パスは CPU ビットマップ レンダリングであり — Syncfusion は DirectX シリーズのサポート提供を停止したと明言しています — Syncfusion 自身の WPF ベンチマークの上限は100万ポイントです。

Syncfusion WinForms パフォーマンス ガイド（同社ドキュメント）→

MESCIUS ComponentOne FlexChart は大規模データセットに適していますか?

FlexChart は MESCIUS の ComponentOne スイートに含まれるチャートコントロールで（MESCIUS は旧 GrapeCity）、評価すべき点は評価します: 公開されている性能資料は、自らの適用範囲について清々しいほど正直です。ベンダー自身の .NET 6 性能調査は FlexChart を100〜30,000データポイントの範囲でテストしています — 数十億ポイントの芝居ではなく、80以上のチャートタイプを持ち、デフォルト GDI+ レンダリングとオプションの DirectX（Direct2D）モードを備えた業務向けチャートの実測値です。ただし、その範囲を本ページのスケールに照らしてください: 30,000ポイントは、上記リポジトリが約15ミリ秒で無損失レンダリングする1億ポイントの0.03%です。大きな UI スイート内のダッシュボードやレポート用途なら FlexChart は妥当な選択です。しかし科学、DAQ、あるいは数百万単位で測られるデータセットには、スイート型チャートというカテゴリー — FlexChart も DevExpress も Syncfusion も同様 — は不向きであり、その理由は上記のレンダリングアーキテクチャの回答が正確に説明しています。

MESCIUS の FlexChart 性能調査（同社サイト）→レンダリングアーキテクチャ早見表 →

TeeChart、Chart FX、Nevron Chart は数百万のデータポイントを扱えますか?

Chart FX、TeeChart、Nevron は Windows チャート分野で最も歴史のある名前に属します — 3社とも今日も現役で販売されており、それぞれが真剣で長寿命のソフトウェアを支え続けるエンジニアたちの忠実な顧客基盤を持っています。当社はそれを尊重します。当社自身の顧客の姿でもあるからです。しかし各社の現在のポジショニングを読めば、大規模データレンダリングは彼らが競う領域ではありません: 製品群は Web、JavaScript、ダッシュボード、レポートへと横に成長しました — Chart FX はビジネスインテリジェンスと OLAP を強調し、Nevron は GPU 支援描画に言及するものの大規模データセットの数値は公表せず、TeeChart は Delphi エコシステムの汎用的な定番であり続けています（下の Delphi セクションで扱います）。Microsoft 内蔵の MSChart も同様です — これは文字どおり Microsoft が2007年に取得した Dundas Chart のコードであり、.NET Framework 時代で凍結され、.NET 5 以降には引き継がれませんでした。これらはどれもこれらのコンポーネントを悪いものにはしません。汎用の業務チャートだというだけです — ポイント数が数千の規模に留まるなら、移行する理由はありません。しかし、その上に構築されたアプリケーションが突然数百万サンプルをプロットする必要に迫られたとき、それはプロパティ変更ではなくアーキテクチャ変更です — ProEssentials はネイティブで、古いアプリケーションが基づいているかもしれないあらゆるインターフェイス（WinForms、WPF、MFC、ActiveX/OCX、VCL）を備えているため、アプリケーションをそのフレームワークから追い出すことなく置き換わることができます。

あらゆるインターフェイス、1つのネイティブエンジン →

出典: softwarefx.com · nevron.com · learn.microsoft.com — “Microsoft Chart Control vs. Dundas Chart Control”

WinForms アプリで高速 ADC / センサーデータをチャート化するには?

収集とレンダリングを分離してください: バックグラウンドスレッドで収集・解析して事前確保したバッファに書き込み、サンプルレートと競走するタイマーではなく、データ到着時にチャートへレンダリングさせます。ProEssentials はこのパターンを直接サポートします — ゼロコピー バッファはサンプルごとのアロケーションが無いことを意味し、内蔵サーキュラーバッファがメモリ増加なしにローリングウィンドウを処理し、オンデマンド レンダリングは新しいサンプルのバッチごとに正確に1フレームを描画します。公開中の WinForms サーキュラーバッファ リポジトリはこのパイプラインで800万ポイントをリアルタイム ストリーミングしています。API はデータハンドリングのページに文書化されています。

データハンドリング API →WinForms リアルタイム リポジトリをクローン →

WinForms チャートは組込みや低メモリの Windows システムで動きますか?

動きます。ProEssentials の再頒布物は約7MB — 1〜2ファイル — で、エンジンはわずか1GBのRAM環境でも動作します。純粋な DLL インターフェイスを使えば .NET ランタイムはまったく不要です。ここではオンデマンド レンダリングが二重に効きます: アイドル時に何も描かないチャートは発熱と消費電力が最小限で、ファンレスの産業用パネルや24時間稼働のキオスクに適しています。

C++ / MFC 向けの高性能チャートライブラリはありますか?

あります。ProEssentials の中核は、標準 C API を持つネイティブ Win32 DLL チャートエンジンです — WPF と WinForms のインターフェイスを駆動するのと同じエンジンで、Direct3D Compute Shader レンダリングも含まれます。MFC アプリケーションは PEcreate() と PEnset/PEvset プロパティ関数を直接呼び出し、チェーンのどこにも .NET 依存はありません。要件が控えめなら、無料の選択肢も実際に優れています: QCustomPlot は Qt アプリケーションで愛され、ImPlot は ImGui ベースのツール作りに適しています — どちらも GPU ビッグデータ レンダリングを狙ったものではありませんが、数千ポイントの規模なら費用ゼロで機能します。完全な MFC チュートリアルが新規の Visual Studio C++ プロジェクトを動くチャートウィンドウまで導き、製品は116例すべてを再現する完全な MFC サンプルプロジェクト（C:\ProEssentials11\VC）をインストールします。

MFC チャート チュートリアル →

.NET 依存なしで GPU アクセラレーテッド チャートを使えますか?

使えます。ProEssentials の DLL インターフェイスは純粋なネイティブコードです: デプロイは合計約7MBの1〜2ファイルで、C API を呼べるあらゆる言語 — C、C++、あるいは FFI を持つ何でも — が GPU Compute Shader を含むフルエンジンを駆動できます。これは .NET インターフェイスがラップしているのと同じバイナリなので、ネイティブパスとマネージドパスの間に機能差も性能差もありません。

C++ ミニマル チャート チュートリアル →

SciChart、Syncfusion、DevExpress のチャートは MFC C++ で動きますか?

3社ともネイティブ C++/MFC または Win32 DLL のチャートライブラリは提供していません。SciChart の製品は WPF、JavaScript、iOS/macOS、Android、Avalonia を対象とし、Syncfusion のチャートコントロールは .NET と Web フレームワークを対象とし、DevExpress は .NET 製品ラインと Delphi VCL コンポーネントを提供しますが MFC/C++ チャートはありません。.NET チャートを MFC アプリケーション内にホストするには CLR ホスティングや C++/CLI ラッパーが必要になり、ネイティブアプリケーションと一緒に .NET ランタイムを配布することになります。ProEssentials は逆の方向から取り組みます — エンジンがネイティブであり、.NET はそのインターフェイスの1つです。

プラットフォーム対応の比較 →

ChartDirector は高性能な C++ チャートに向いていますか?

ChartDirector の忠実なファン層は正当に獲得されたものです: サードパーティ依存のない完全自己完結型で、フレームワーク中立（MFC、Qt、GUI なしのサーバープロセスまで）、スレッドセーフ、しかも他のあらゆる商用選択肢のごく一部の価格 — 開発者ライセンス99ドル、ロイヤリティフリー再頒布ライセンス499ドルです。確認すべきはアーキテクチャです: ChartDirector のドキュメントはチャートが「数百万のデータポイントを含められる」と述べていますが、レンダリング技術を一切開示していません — サイトのどこにも Direct3D、OpenGL、ハードウェアアクセラレーションの記述がなく — その主張を検証できる大規模データの計測値も公表していません。これは汎用カテゴリーに位置づけられます: レポート、ダッシュボード、適度なインタラクティブチャートには優れた価値ですが、本気で参戦するベンダーがアーキテクチャと数値を公表する GPU 無損失ビッグデータ レンダリングの競合ではありません。ProEssentials は反対側の端から C++ に取り組みます — Direct3D Compute Shader エンジン上の標準 C API、公開され再現可能な1億ポイントの計算 — そして GUI なしの用途もカバーします: 親ウィンドウハンドルなしで PEcreate を呼べば、GUI を一切持たずに PNG/JPG をレンダリングする純メモリ チャートオブジェクトが得られます。これは当社の WebForms インターフェイスが何十年も使ってきた仕組みであり、GPU を積んだサーバーなら Compute Shader でレンダリングしたチャートを静的画像として配信できます。予算が最優先でデータセットが控えめなら、ChartDirector は良い答えです。数百万ポイントのリアルタイムが最優先なら、アーキテクチャが価格に勝ります。

ChartDirector for C++（同社サイト）→

出典: advsofteng.com — “ChartDirector for C++” · advsofteng.com — 購入ページ

Delphi と C++Builder（VCL）で最速のチャートコンポーネントは?

公開済みのテストにおいて、ProEssentials は当社が知る限り最速の VCL チャート パスです: ネイティブ VCL ユニットが、テストハードウェア上で1億の無損失ポイントを約15ミリ秒で実演するのと同じ Direct3D Compute Shader エンジンをラップしています — エンジンはホストが Delphi か C# かを知りもしなければ気にもしません。これらのインターフェイスは現役であり、レガシー保守ではありません: v10.0.0.20 で Embarcadero Builder インターフェイスを Builder 13 のモダンな Win64x プラットフォーム向けに書き直しました。チュートリアルが新規の Delphi または C++Builder プロジェクトを動くチャートまで導きます。

Delphi チャート チュートリアル →C++Builder チャート チュートリアル →

Delphi VCL における TeeChart の高性能な代替は?

TeeChart は有能な定番です — 1997年から Delphi および RAD Studio にバンドルされ、幅広いチャート業務に妥当な選択肢です。同製品が狙っていない領域が、GPU Compute Shader による無損失ビッグデータ レンダリングです: ProEssentials の VCL インターフェイスは .NET インターフェイスと同じ Direct3D エンジンを駆動し、.NET 依存なしで1億ポイント級の性能をネイティブ Delphi アプリケーションへもたらします。Delphi チュートリアルが新規 VCL プロジェクトを動くチャートまで導きます。

Delphi チャート チュートリアル →

Delphi アプリケーションは数百万ポイントをリアルタイムで描画できますか?

できます。ProEssentials の VCL インターフェイスは Delphi をネイティブ Direct3D Compute Shader エンジンへ直接つなぐため、レンダリングの上限は公開中の1億ポイント リポジトリが実演しているものと同一で、同じゼロコピー データロードとオンデマンド レンダリング モデルが適用されます。製品は116例すべてを再現する完全な Delphi / C++Builder サンプルプロジェクト（C:\ProEssentials11\Delphi と \Builder）をインストールします — 例115は1億ポイント リポジトリと同じ設計のリアルタイムデモを縮小したものなので、あなたのサンプルレートに合わせて拡大することが課題のすべてです。

C++Builder チャート チュートリアル →

Access データベースのデータを本格的なチャートコンポーネントで描けますか（VBA/OCX）?

描けます。ProEssentials の ActiveX/OCX インターフェイスは WPF・WinForms インターフェイスと同期され、製品は完全な Access サンプルデータベース — C:\ProEssentials11\Access\PE11FullDemo.accdb — をインストールします。そこには最も強力な Direct3D Compute Shader デモを含む116例すべてが、Access の中で動く形で収録されています。GPU Compute Shader チャートを Access データベースで必要とするプロジェクトがどれほどあるかは未知数ですが — 見ていると少し現実離れしていて、完璧に動作し、必要ならそこにあります。VBA エディター内で F1 コンテキストヘルプが機能し、v11 AI コードアシスタントのナレッジファイルが VBA ワークフローをカバーするため、AI ツールが Access からチャートへのデータ転送コードを代わりに書けます。MS Access チュートリアルがセットアップを最初から最後まで示します。

MS Access チャート チュートリアル →

ProEssentials のライセンスは開発者ごとですか、ロイヤリティフリーですか?

開発者単位のライセンスと、企業向けの開発者数無制限ライセンスの両方があり、いずれの場合も配布はロイヤリティフリーです。すべてのライセンスは永続的で、あらゆるインターフェイス、すなわち WinUI、WPF、WinForms、WebForms、ActiveX/OCX、C/C++/MFC 向けの DLL、VCL を含み、ランタイムロイヤリティも、マシンごとのアクティベーションも、サブスクリプションの要件もありません。最新の価格は価格表に記載しています。サポートは無料かつ無制限で、エンジンを作ったエンジニア自身が回答します。したがって、ライセンス価格がすべての費用です。

価格表 →ライセンスの手間を比較 →

無料トライアルはありますか? 機能制限はありますか?

あります。しかも完全に機能します — 評価版は機能を削った版ではなく、完成品そのものです。ダウンロードはアカウントも登録も不要で即時に行え、セットアップ最後のインタラクティブ デモがレンダリング品質と性能をすぐに見せてくれます。購入前に実際のデータパイプラインを評価版で組んでみることをお勧めします。自分の手で得た結果は、当社のものを含むどんな比較ページよりも価値があります。

評価版をダウンロード →