高速で応答性の高いインタラクティブなチャート/グラフ：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/
d3.js は、Protovisから生まれたもので、SVGベースであり、 アニメーションのレンダリングが優れていると想定されています です。ただし、パフォーマンスの上限がどれほど優れているのか、疑問があります。そのため、 KineticJS のようなキャンバスベースのライブラリを使用して、より完全なオーバーホールを検討しています。ただし、あるアプローチを使い始める前に、このようなデータを使用して同様のWebアプリケーションを作成した人から意見を聞きたいと思います。
最も重要なことはパフォーマンスであり、他のインタラクション機能の追加とアニメーションのプログラミングの容易さに重点を置いています。おそらく、一度に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（ demo 、 code ）の実装を行った経験がある場合は、あなたからも連絡をもらいたいと思います。データを操作し、それをレンダリングする方法（およびパフォーマンス）をカスタム制御できるという優れたハイブリッドのように見えますが、DOMにすべてをロードしなければならない場合でも、物事が遅くなるのではないかと思います。
この質問に似た既存の質問がいくつかあることは知っていますが、まったく同じことを尋ねる質問はありません。ご協力いただきありがとうございます。
フォローアップ：私が使用することになった実装は https://github.com/zooniverse/LightCurves にあります
幸いなことに、2000個の円を描くことはテストするのに非常に簡単な例です。そのため、CanvasとSVGのそれぞれ2つの4つの可能な実装があります。
これらの例では、D3の zoom behavior を使用してズームとパンを実装しています。円がCanvasまたはSVGでレンダリングされるかどうかは別として、他の主な違いは、geometricまたはsemanticズームを使用するかどうかです。
幾何学的ズームとは、ビューポート全体に単一の変換を適用することを意味します。ズームインすると、円が大きくなります。セマンティックズームとは対照的に、各円に個別に変換を適用することを意味します。ズームインすると、円は同じサイズのままですが、広がります。現在、Planethunters.orgはセマンティックズームを使用していますが、他のケースを検討することは有用です。
幾何学的なズームにより、実装が簡単になります。変換とスケールを一度適用すると、すべての円が再レンダリングされます。 SVG実装は特に単純で、単一の「変換」属性を更新します。両方の幾何学的ズームの例のパフォーマンスは十分すぎると感じています。セマンティックズームの場合、D3はProtovisよりも大幅に高速であることに気付くでしょう。これは、ズームイベントごとの作業量が大幅に少ないためです。 （Protovisバージョンは、すべての要素のすべての属性を再計算する必要があります。）Canvasベースのセマンティックズームは、SVGよりもわずかにジッピーですが、SVGセマンティックズームは、依然として応答性があります。
まだパフォーマンスに魔法の弾丸はありません、そして、これらの4つの可能なアプローチは可能性のすべてのスペースをカバーし始めません。たとえば、幾何学的およびセマンティックズーム。パン（「変換」属性の更新）に幾何学的アプローチを使用し、ズーム中は個々の円のみを再描画します。これらのテクニックの1つ以上をCSS3変換と組み合わせて、ハードウェアアクセラレーションを追加することもできます（ hierarchical Edge bundling example ）.
それでも、私の個人的な好みはSVGを可能な限り維持し、レンダリングがボトルネックである場合に「内部ループ」にのみCanvasを使用することです。 SVGには、CSS、データ結合、要素インスペクターなど、開発に非常に多くの利便性があるため、多くの場合、Canvasから始めるのは時期尚早な最適化です。リンクしたFacebook IPO視覚化のようにCanvasとSVGを組み合わせると、これらの利便性のほとんどを維持しながら、最高のパフォーマンスを引き出す柔軟な方法です。また、この手法を Cubism.js で使用しました。ここでは、時系列の視覚化の特殊なケースがビットマップキャッシュに適しています。
これらの例が示すように、D3の一部はSVG固有ですが、CanvasでD3を使用できます。こちらもご覧ください force-directed graph とこちら 衝突検知の例 .
あなたのケースでは、canvasとsvgの決定は、「馬に乗る」か「ポルシェを運転する」かの決定とは異なると思います。私にとっては、車の色に関する決定に似ています。
説明させてください：フレームワークに基づいて、
- 星を描く、
- スターを追加して
- 星を削除する
線形の時間がかかります。したがって、フレームワークの決定が良かった場合は少し速くなり、そうでなければ少し遅くなります。
フレームワークがちょうど速いと仮定すると、大量の星が原因でパフォーマンスの低下が引き起こされることが完全に明らかになり、それらを処理することはフレームワークのどれもあなたのためにできないことです、少なくとも私は知らないこれについて。
私が言いたいのは、問題の根本が計算幾何学の基本的な問題につながるということです。つまり、 範囲検索 とコンピューターグラフィックスのもう1つ： 詳細レベル です。
パフォーマンスの問題を解決するには、表示する星を非常に高速に見つけることができ、ズームに応じて互いに近い星をクラスター化できる優れたプリプロセッサを実装する必要があります。ビューを鮮明かつ高速に保つ唯一の方法は、星の数をできるだけ少なくすることです。
あなたが述べたように、最も重要なことはパフォーマンスです。canvasはDOM操作なしで機能するので、canvasを使用する傾向があります。また、グラフィックパフォーマンスを大幅に向上させるwebGLを使用する機会も提供します。
ところで： paper.js をチェックしましたか？キャンバスを使用しますが、ベクターグラフィックスをエミュレートします。
PS： この本では ウェブ上のグラフィックス、テクノロジー、キャンバス、SVG、DHTMLの長所と短所に関する非常に詳細な議論を見つけることができます。
最近、ほぼリアルタイムのダッシュボード（5秒ごとに更新）で作業し、キャンバスを使用してレンダリングするチャートを使用することを選択しました。
Highcharts（SVGベースのJavaScriptチャートライブラリ）とCanvasJS（キャンバスベースのJavaScriptチャートライブラリ）を試しました。 Highchartsは素晴らしいチャート作成APIであり、CanvasJSを使用することを決めたより多くの機能を提供します。
チャートごとに少なくとも15分のデータを表示する必要がありました（最大2時間の範囲を選択するオプションを使用）。
15分間：900ポイント（1秒あたりのデータポイント）x2（線と棒の組み合わせチャート）x4チャート=合計7200ポイント。
chromeプロファイラを使用すると、CanvasJSではメモリが30MBを超えることはありませんでしたが、Highchartsではメモリ使用量が600MBを超えました。
また、5秒の更新時間で、CanvasJSレンダリングはHighchartsよりも応答性が高くなりました。
1つのタイマー（setInterval 5秒）を使用して4 REST API呼び出しを行い、Elasticsearchに接続したバックエンドサーバーからデータをプルしました。データがJQuery.post（）で受信されるたびに更新される各チャート。
それは、オフラインレポートについては、より柔軟なAPIであるため、Highchartsを使用します。
また、SVGまたはCanvasのいずれかを使用していると主張しているが、それらを確認していないZingチャートもあります。
パフォーマンスが本当に重要な場合は、Canvasを検討する必要があります。柔軟性のためのSVG。キャンバスフレームワークが柔軟ではないというわけではありませんが、キャンバスフレームワークがsvgフレームワークと同じ機能を取得するには、より多くの作業が必要です。
また、超高速KineticJSフレームワークの上に構築されたMeteor Chartsを調べることもできます。 http://meteorcharts.com/