高速で応答性の高いインタラクティブなチャート/グラフ：SVG、Canvas、その他？

私は、ズーム可能なパン可能なグラフで基本的に何千ものポイントをレンダリングするプロジェクトを更新するために使用する適切なテクノロジーを選択しようとしています。Protovisを使用した現在の実装は、パフォーマンスが低いです。ここでそれをチェックしてください：

http://www.planethunters.org/classify

完全に縮小すると約2000ポイントになります。下部のハンドルを使用して少し拡大し、ドラッグして移動します。あなたはそれがかなり途切れ途切れであり、あなたが本当に速いコンピュータを持っていない限り、あなたのCPU使用率はおそらく1つのコアで100％に上がることがわかります。フォーカスエリアへの変更ごとにprotovisへの再描画が呼び出されますが、これはかなり遅く、描画されるポイントが多いほど悪くなります。

インターフェースにいくつかの更新を加え、基礎となる視覚化テクノロジーを変更して、アニメーションとインタラクションの応答性を高めたいと思います。次の記事から、別のSVGベースのライブラリか、キャンバスベースのライブラリを選択するように見えます。

http://www.sitepoint.com/how-to-choose-between-canvas-and-svg/

Protovisから生まれたd3.jsはSVGベースであり、アニメーションのレンダリングに優れているはずです。ただし、パフォーマンスの上限がどれほど優れているかについては疑問です。そのため、KineticJSのようなキャンバスベースのライブラリを使用して、より完全なオーバーホールも検討しています。ただし、1つのアプローチを使い始める前に、これだけ多くのデータを使用して同様のWebアプリケーションを実行した人からの意見を聞き、意見を聞きたいと思います。

最も重要なのはパフォーマンスです。2番目の焦点は、他の対話機能の追加とアニメーションのプログラミングの容易さにあります。おそらく、一度に2000ポイントを超えることはなく、それぞれに小さなエラーバーがあります。ズームイン、ズームアウト、パンニングはスムーズである必要があります。最新のSVGライブラリがこれで適切な場合、おそらくd3の使いやすさはKineticJSなどの設定の増加よりも優先されます。ただし、キャンバスを使用することで、特に低速のコンピューターを使用する人にとって、パフォーマンスに大きな利点がある場合は、間違いなくその方法を好むでしょう。

NYTimesが作成した、SVGを使用しているが、順調にスムーズにアニメーション化するアプリの例：http : //www.nytimes.com/interactive/2012/05/17/business/dealbook/how-the-facebook-offering-compares.html。そのパフォーマンスが得られ、独自のキャンバス描画コードを記述する必要がない場合は、おそらくSVGを使用します。

一部のユーザーは、キャンバスレンダリングと組み合わせたd3.js操作のハイブリッドを使用していることに気付きました。しかし、私はこれについてオンラインで多くのドキュメントを見つけることができないか、その投稿のOPに連絡することができません。このようなDOM-to-Canvas（デモ、コード）の実装を経験したことがある方は、ぜひご連絡ください。データを操作できることと、データのレンダリング方法（したがってパフォーマンス）をカスタム制御できることの良いハイブリッドのようですが、すべてをDOMにロードしなければならない場合でも、処理が遅くなるのではないかと思います。

これに似た既存の質問がいくつかあることは知っていますが、まったく同じことを尋ねる質問はありません。ご協力いただきありがとうございます。

フォローアップ：私が最終的に使用した実装はhttps://github.com/zooniverse/LightCurvesにあります

幸い、2000個の円を描くことは、テストするのが非常に簡単な例です。したがって、4つの可能な実装があり、それぞれ2つのCanvasとSVGです。

• キャンバスの幾何学的なズーム
• キャンバスのセマンティックズーム
• SVG幾何学的ズーム
• SVGセマンティックズーム

これらの例では、D3のズーム動作を使用して、ズームとパンを実装しています。脇の円をキャンバスやSVGでレンダリングされているかどうかから、他の主要な違いは、使用するかどうかである幾何学的またはセマンティックズームを。

幾何学的ズームとは、ビューポート全体に単一の変換を適用することを意味します。ズームインすると、円が大きくなります。意味的なズームとは対照的に、各円に個別に変換を適用します。ズームインすると、円は同じサイズのままですが、広がります。Planethunters.orgは現在、セマンティックズームを使用していますが、他のケースを検討することも役立つ場合があります。

幾何学的なズームにより、実装が簡素化されます。変換とスケーリングを一度適用すると、すべての円が再レンダリングされます。SVG実装は特に単純で、単一の「変換」属性を更新します。両方の幾何学的ズームの例のパフォーマンスは、十分すぎるほど感じられます。セマンティックズームの場合、D3がProtovisよりも大幅に高速であることがわかります。これは、各ズームイベントでの処理がはるかに少ないためです。（Protovisバージョンは、すべての要素のすべての属性を再計算する必要があります。）Canvasベースのセマンティックズームは、SVGよりも少し簡単ですが、SVGセマンティックズームは依然として応答性が高く感じられます。

しかし、パフォーマンスに特効薬はありません。これらの4つの可能なアプローチは、可能性のすべての領域をカバーし始めていません。たとえば、ジオメトリックアプローチとセマンティックズームを組み合わせて、パンの幾何学的アプローチ（「変換」属性を更新）を使用して、ズーム中に個々の円のみを再描画することができます。これらの手法の1つ以上をCSS3変換と組み合わせて、ハードウェアアクセラレーションを追加することもできます（階層的なエッジバンドリングの例のように）。ただし、実装が難しく、視覚的なアーティファクトが生じる場合があります。

それでも、私の個人的な好みは、可能な限りSVGを維持し、レンダリングがボトルネックになっている場合に「内部ループ」にのみCanvasを使用することです。SVGは、CSS、データ結合、要素インスペクターなど、開発に非常に多くの便利さを備えているため、Canvasから始めるのは時期尚早です。リンクしたFacebook IPOの視覚化のように、CanvasをSVGと組み合わせると、これらの便利な機能のほとんどを維持しながら、最高のパフォーマンスを引き出すことができます。また、この手法をCubism.jsで使用しました。時系列視覚化の特殊なケースは、ビットマップキャッシュに適しています。

これらの例が示すように、D3の一部がSVG固有である場合でも、D3をCanvasで使用できます。この力指向のグラフとこの衝突検出の例も参照してください。

あなたの場合、canvasとsvgの間の決定は、「馬に乗る」または「ポルシェ」を運転する間の決定とは違うと思います。私にとっては、車の色についての決定のようなものです。

説明させてください：前提として、フレームワークに基づいて操作

• 星を描く
• スターを付けて
• スターをはずす

線形の時間がかかります。したがって、フレームワークの決定が良かった場合は少し速くなり、そうでない場合は少し遅くなります。

フレームワークがただ速いと仮定し続けると、パフォーマンスの欠如が引き起こされていることが明らかになり、星の数が多いためにそれらを処理することは、フレームワークのどれもあなたのためにできないことです、少なくとも私は知りませんこれについて。

私が言いたいのは、問題の根本は、計算幾何学の基本的な問題、つまり、範囲検索とコンピュータグラフィックスのもう1つの問題、詳細レベルにつながるということです。

パフォーマンスの問題を解決するには、表示する星を非常に高速に検出でき、ズームによっては、近接している星をクラスター化できる優れたプリプロセッサを実装する必要があります。ビューを鮮明かつ高速に保つ唯一の方法は、描画する星の数をできるだけ少なくすることです。

あなたが述べたように、最も重要なことはパフォーマンスであり、DOM操作なしで機能するため、キャンバスを使用する傾向があります。また、グラフィックのパフォーマンスを大幅に向上させるwebGLを使用する機会も提供します。

ところで：paper.jsをチェックしましたか？キャンバスを使用しますが、ベクターグラフィックスをエミュレートします。

PS：この本では、ウェブ上のグラフィックス、テクノロジー、キャンバスの長所と短所、SVG、DHTMLに関する非常に詳細な説明を見つけることができます。

私は最近、ほぼリアルタイムのダッシュボード（5秒ごとに更新）で作業し、キャンバスを使用してレンダリングするチャートを使用することを選択しました。

Highcharts（SVGベースのJavaScriptチャートライブラリ）とCanvasJS（CanvasベースのJavaScriptチャートライブラリ）を試しました。Highchartsは素晴らしいチャートAPIであり、CanvasJSを使用することを決定した方法をさらに多く提供します。

グラフごとに少なくとも15分のデータを表示する必要がありました（最大2時間の範囲を選択するオプションがあります）。

したがって、15分間の場合：900ポイント（データポイント/秒）x2（折れ線と棒の組み合わせのグラフ）x4のグラフ=合計7200ポイント。

CanvasJSでChromeプロファイラーを使用すると、メモリが30MBを超えることはありませんが、Highchartsではメモリ使用量が600MBを超えました。

また、5秒の更新時間で、CanvasJSレンダリングはHighchartsよりも応答性が高くなりました。

1つのタイマー（setInterval 5秒）を使用して4つのREST API呼び出しを行い、Elasticsearchに接続しているバックエンドサーバーからデータをプルしました。データがJQuery.post（）によって受信されるときに更新される各グラフ。

つまり、オフラインレポートの場合、より柔軟なAPIであるHighchartsを使用します。

SVGまたはCanvasのいずれかを使用することを主張しているが、まだそれらを表示していないZingチャートもあります。

パフォーマンスが非常に重要な場合は、キャンバスを検討する必要があります。柔軟性のためのSVG。キャンバスフレームワークは柔軟性がないわけではありませんが、キャンバスフレームワークがsvgフレームワークと同じ機能を取得するには、さらに多くの作業が必要です。

また、超高速のKineticJSフレームワークの上に構築されたMeteor Chartsも調べてみてください。http：//meteorcharts.com/

また、SVGグラフィックを含むページをPDFに印刷すると、結果のPDFには依然としてベクターベースの画像が含まれていますが、Canvasグラフィックを含むページを印刷すると、結果のPDFファイルの画像がラスタライズされます。