したがって、実装する必要があるのは、いくつかのノード (最大数百) を持つツリー メニューです。ノードは子を持つことができ、展開/折りたたむことができます。マウス オーバーによる背景の稲妻と、マウス選択による背景の稲妻もあります。各ノードには、ボックス、アイコン、およびテキストがあり、非常に大きくなり、画面全体の幅を占める場合があります。
これは、すでに機能しているソリューションの例です。
基本的に私は：
可能な背景のハイライトの長さを取得するためだけに、テキストを初めてレンダリングする
ボックスとアイコン テクスチャのレンダリング (はい、現時点では逆さまになっています)
テキストを 2 度目にレンダリングします。最初に太字をすべてレンダリングし、次に通常のテキストをすべてレンダリングします。
このソリューションは、実際には比較的許容可能なパフォーマンスへの影響があります。
次に、別の方法を試しました。つまり、g Graphic Java を使用してツリー メニューを描画し、それを bufferedImage として返し、最後に大きなテクスチャを作成してそれをレンダリングします。これは明らかに、すべてのノードの折りたたみ/展開、およびマウスの移動ごとに行われます。
これははるかに優れたパフォーマンスを発揮しましたが、 Java は古い bufferedImages の処理に大きな問題を抱えているようです。実際、RAM の消費量は絶えず増加し、ガベージ コレクションを強制してもメモリの増加はわずかに改善されますが、速度が低下しますが、それでも...さらに、ガベージ コレクタが毎回呼び出され、まったく軽くないように見えるため、パフォーマンスが低下します。
だから私があなたに尋ねようとしているのは、私のニーズに最適な戦略はどれですか?
各ノードを異なるテクスチャ (実際には 3 つ: 1 つは通常、1 つはマウス オーバー用の明るい背景、最後の 1 つはマウス選択用の通常の背景) でレンダリングし、次に各 display() ですべてを結合することも可能です。これらのテクスチャは現在のツリー メニューの状態ですか?