3

pygtk を使用して Maemo プラットフォーム用のアプリケーションを作成していますが、ツリー ビューのレンダリング速度が問題のようです。アプリケーションはメディア コントローラーなので、UI でトランジション アニメーションを使用しています。これらのアニメーションは、UI 内を移動するときにコントロールをスライドさせて表示します。ツリー コントロールの問題は、遅いことです。

画面の中央でウィジェットを移動するだけではそれほど遅くはありませんが、セルが露出している場合はフレームレートが実際に低下します. これをより厄介にしているのは、露出されている唯一の領域が行ラベルを持つタイトル行である場合、フレームレートは制御下にあることです.

このことから判断すると、1 行のピクセルが表示されるたびに、GTK ツリー ビューが完全なセルを再度描画していると思われます。ウィジェットの一部が画面外にある場合でも、ウィジェット全体を何らかのバッファに描画し、アニメーション時にバッファを使用してウィジェットを描画するように何らかの方法で強制する方法はありますか?

また、ビューポートを使用して上にスクロールすることと、レイアウト パネルを使用してウィジェットを下に移動することに違いはありますか? Viewport の方が速いと想像していましたが、両方のバージョンを試してみたところ、実際の違いは見られませんでした。

これは、必ずしも GTK が作成された目的ではないことを理解しています。私が試した他の代替手段はpygameですが、ウィジェットベースのイベント処理が組み込まれた高レベルの実装を好むでしょう。また、pygtkにはWindowsとウィンドウで実行できるという利点があるため、開発が容易になります。

4

1 に答える 1

1

私はこれを自分で行ったことはありませんが、キャッシュを自分で実装しようとすることができます。定義済みのセル レンダラーを使用する代わりに、独自のセル レンダラーを (おそらく実際のセル レンダラーのラッパーとして) 実装しますが、ピックスマップをキャッシュします。

PyGTK では、 を使用できますgtk.GenericCellRenderer。デコレーター セル レンダラーで、レンダリングを求められたら、次の操作を行います。

  • オフスクリーン ピックスマップのキャッシュ (または、大きなものを 1 つだけ) とサイズのキャッシュを保持する
  • サイズまたはレンダリングを予測するよう求められた場合は、関連するプロパティからキーを作成します
  • キーがキャッシュに存在する場合は、キャッシュされたピックスマップを使用し、指定されたドローアブルでキャッシュされたピックスマップをブリットします
  • それ以外の場合は、まず実際のセル レンダラーに作業を行わせてからコピーします。

最後のステップは、セルが最初にレンダリングされるときに、キャッシュによってオーバーヘッドが発生することも意味します。この問題は、キャッシュ戦略を使用することで少し軽減できます。レンダリングされた値の分布に基づいて、さまざまなことを試してみてください。

  • すべてのセルが一意である場合、特定の制限まですべてをキャッシュするか、MRU 戦略を実行するよりも多くのことを行う必要はありません。
  • ある種のZipf 分布がある場合、つまり、非常に一般的なセルと非常にまれなセルがある場合は、頻繁にセルをキャッシュし、まれなセル値のキャッシュ オーバーヘッドを取り除く必要があります。

そうは言っても、それが違いを生むかどうかは言えません。やや似た問題からの私の経験は、テキストを含むものは通常、キャッシングが理にかなっているほど遅いということです---申し訳ありませんが、これ以上簡単なアドバイスはできません。

それを試す前に、セルが実際にレンダリングされる頻度をカウントし、タイミング情報を取得する装飾セルレンダラーを簡単に作成して、ホットスポットがどこにあり、値をキャッシュすることが意味があるかどうかを把握することもできます。まったく。

于 2009-07-15T22:29:10.687 に答える