多数の小さな棒グラフ (スパークライン サイズ) を必要とする設計があります。典型的なページには、グラフごとに 100 以上のデータポイントを示す 60 以上のグラフが簡単に表示されます。そのようなもののブラウザー内のメモリフットプリントは法外なものでしょうか? png を出力するサーバー側のレンダラーを使用することもできますが、SVG を使用するとさらに多くのことができるようです。
その他の考慮事項: SVG は Rapheal.js によって IE 用の VML に変換される可能性があります。そのため、そこにあるメモリ フットプリントも合理的である必要があります。
良い答えを見つけるための助けや方法論は大歓迎です。
あなたが説明するsvg要素の量は、メモリ消費の点で確かに問題を引き起こす可能性があります.
canvas 要素とは対照的に、SVG では、ブラウザが表現されるすべての要素のオブジェクト モデルを維持する必要があります。このオブジェクト モデルを使用すると、イベントを特定の要素のクリックに簡単に関連付けることができます。正方形が画面上のどこにあるか、大きさ、スケーリングなどを追跡する必要はありません。ただし、これにはメモリ要件の代償が伴い、心配するだけのキャンバス タグとは対照的です。ピクセルをペイントする色について、また、どの「オブジェクト」がクリックされたかを追跡することについて心配する必要があります。
したがって、パフォーマンスが問題になるかどうかを判断しようとするときは、通常、対象となるハードウェアに関して、いわば最小公分母から始めるのが賢明です。モバイルデバイスをターゲットにしていますか? ラップトップとデスクトップをターゲットにしていますか?
その質問に対する答えが得られたら、そのハードウェアをターゲットにして、1 つのダミー グラフ (100 データ ポイント) を 60 回繰り返し使用するダミー アプリケーションを作成します。ユーザーがディスプレイを操作する方法を反映した方法でディスプレイを操作できるように、十分に構築します (ユーザーがグラフをスライドできるようにする場合は、それを含める必要があります)。
そのダミーのプロトタイプを使用して、基本的な対話を使用してみて、パフォーマンスが要件 (つまり、アプリケーションの対象ユーザーの期待) を満たしているかどうかを確認してください。
この種のアプリのパフォーマンス向上に関しては、ajax と svg を組み合わせて使用することをお勧めします。グラフのサムネイルを生成し (SVG を使用すると、詳細が削減されるためフットプリントがはるかに小さくなります)、ユーザーが詳細を取得することを決定すると、ajax を使用してその特定のより詳細な SVG 表現を取得します。グラフ。
アプリの作成をお楽しみください :)
SVG スパークラインに PNG 代用を使用し、必要に応じて SVG をプルダウンするという Adam のアイデアが気に入っています。これらは、 librsvgやCairoなどのライブラリに供給される同じ SVG ソースを使用して、サーバー側で簡単にレンダリングできます。
キャンバスを使用するもの (IE の自動回避策を備えたもの) を探している場合は、jQuery Sparklinesライブラリを参照してください。必要なすべてが既に実行されている可能性があります。
データの正規化が重要です。ほとんどの場合、幅 50 ピクセルのスパークラインでは、100 個のデータ ポイントは不要であり、人間の目には目立ちません。データの正規化を使用して、100 ポイントから 5 ポイントに減らします。これにより、目に優しく、パフォーマンスが向上します。
サーバー側のスパークライン イメージ スプライトは、多数のスパークラインがある場合、フロントエンドの SVG/Canvas で生成されたスパークラインよりも優れている傾向があります。
これは、優れた PNG 圧縮を使用する Java の高速なサーバー側スパークライン ソリューションです。