115

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

http://www.planethunters.org/classify

完全にズームアウトすると、約 2000 ポイントあります。下部のハンドルを使用して少しズームインし、ドラッグしてパンします。非常に高速なコンピューターを使用していない限り、CPU 使用率が 1 つのコアで 100% に達する可能性があります。フォーカス領域を変更するたびに、プロトビスへの再描画が呼び出されますが、これは非常に遅く、より多くのポイントが描画されると悪化します。

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

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

Protovis から派生したd3.jsは 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 からキャンバスへの ( demo、code ) 実装を行った経験のある方がいらっしゃいましたら、ご連絡をお待ちしております。データを操作できることと、それをレンダリングする方法 (したがってパフォーマンス) をカスタム制御できることの良いハイブリッドのようですが、すべてを DOM にロードする必要があると、それでも速度が低下するのではないかと思います。

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

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

4

5 に答える 5

186

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

これらの例では、D3 のズーム動作を使用して、ズームとパンを実装しています。円が Canvas でレンダリングされるか 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 固有ですが、Canvas で D3 を使用できます。この力指向グラフとこの衝突検出の例も参照してください。

于 2012-09-08T23:59:17.440 に答える
9

あなたの場合、canvasとsvgのどちらを選択するかは、「馬に乗る」か「ポルシェ」を運転するかの決定とは異なります。私にとって、それは車の色についての決定のようなものです。

説明させてください：それを仮定すると、フレームワークに基づいて操作

  • 星を描く、
  • 星を追加して
  • 星を削除します

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

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

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

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

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

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

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

于 2012-09-08T11:45:37.930 に答える
7

私は最近、ほぼリアルタイムのダッシュボード (5 秒ごとに更新) に取り組み、キャンバスを使用してレンダリングされるチャートを使用することにしました。

Highcharts(SVG ベースの JavaScript Charting ライブラリ) と CanvasJS(Canvas ベースの JavaScript Charting ライブラリ) を試しました。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 フレームワークと同じ機能を実現するには、より多くの作業が必要です。

于 2014-08-07T15:47:19.507 に答える
3

また、非常に高速な KineticJS フレームワークの上に構築された Meteor Charts を調べることもできます: http://meteorcharts.com/

于 2013-05-31T05:22:45.423 に答える