Silverlight 4のビットマップキャッシュの欠点は何ですか？

Question

私たちは、ここで説明するように、シルバーのビットマップキャッシュを利用することにより、高いCPU使用率の問題を解決することができました：

• Silverlight 3 and GPU Acceleration
• Discovering Silverlight 3 – Deep Dive into GPU Acceleration

我々は<オブジェクトにEnableGPUAccelerationパラメータを追加しました>タグ。 CPU使用量を適切なレベルに下げるために、アプリケーション全体のルートビジュアルグリッドにCacheMode = "BitmapCache"を追加する必要がありました。だから私は、ビットマップキャッシュにあまり依存していないという欠点があるのだろうかと思っています。それが常に有益だったなら、私はそれがデフォルトで有効になると思います。

私はAnthonyWJonesによって良い答えでこれと同様の問題が見つかりました：

• Any reason not to check “application library caching” and “GPU acceleration” in silverlight apps?

だから、1の欠点は、それがより多くのビデオRAMを使用することです。私はこれが、他のグラフィックスを集中的に使っているアプリケーションが同時に動作することを悪化させる可能性があると思う。他にも欠点はありますか？

ビデオカードにすべてのものをキャッシュするのに十分なビデオRAMがない場合は、Silverlightが正常に機能しなくなり、UIを再レンダリングするためにCPUサイクルが増えると想定します。あなたの助けのための

おかげで、
リチャード

Answer 1

ビットマップキャッシュを多用して実験したところ、アプリケーションではこれをオフにしました。アニメーション、スキッシュ、回転などのような画像がある場合など、GPUを使用して変更されていないUIの変形を実行したいときにうまくいきます。しかし、ビットマップキャッシング/ GPUアクセラレーション（現在の実装では）は、UIの内部でキャッシュ/操作したいビジュアルツリーを更新し続けている場合、かなり劇的に遅くなります。静的なビットマップを移動するだけの場合は、キャッシュしてGPUを使用して高速化してください。しかし、キャッシュにフラグを立てたUIの部分から、ビジュアルツリーのどこかで作品を調整していることがあります。そのような場合は、GPUのキャッシュを各フレームごとに更新する必要があります。

つまり、オンにするかどうかは、になります。ここでは、をオンにして、アプリケーションが何をしているかによって決まります。このため、ビットマップキャッシュを使用している場合やSilverlight UIのパフォーマンスに問題がある場合は、（一時的に）cache visualizationとredraw regionsを有効にすることを強くお勧めします。あなたのアプリは、あなたのアプリが気に入っているように見えるようにしますが、あなたのUIが何をしているかを見れば、すべてのCPUを噛んでいます。

Answer 2

私はあなたが説明したものに懸念を見ませんが、私はあなたがオーバービットマップキャッシュを使用することができると信じています。

たとえば、500x500の「トップ」キャンバスがあり、それに100x100の25個の「サブ」キャンバスが含まれているとします。サブカンバスごとにコンテンツや色などを更新しています。トップキャンバスを画面上に移動させるイベントがあったとします。すべてのサブキャンバスが同じ間隔で変更された場合は、トップキャンバスのみをビットマップキャッシュすることが理にかなっています。ただし、サブキャンバスがすべて同じ間隔で変更されない場合や、まったく変更されない場合は、代わりに各サブキャンバスでビットマップキャッシングを設定する方が効果的です。この一歩をさらに進めてくださいトップと各サブキャンバスの両方をビットマップキャッシュすると、無益なキャッシュで無駄なサイクルが発生する可能性があります。

または、私はあなたが求めているものとは全く別の道を歩いていますか？