JFrameで描画するのがJPanelよりもずっと遅いのはなぜですか？

Question

私の質問は、JFrameで直接描画した場合と比べてJPanelで描画すると、同じスイングカスタム描画ルーチンがほぼ16倍高速になるのはなぜですか？ダブルバッファリングですか？確かにできない？

背景：JFrameが保護されていない（特に部分的にしか見えない）ときに、カスタムペイントがリフレッシュされないという問題がありました。 SOを検索した後、私はJPanelのサブクラスをbluddy-NetBeans-form-designerフォームに配線する方法を決定しました。

同じ状況の人：NetBeansでは、ちょうどJPanelを拡張する新しい標準クラス（JPanelフォームではない）を作成し、そこにあるすべてのコードを手作業でコーディングする必要があります（GUIデザイナーなし、オレ日、一息）。次に、標準のJPanelをフォームに追加し、サイズを設定します。右クリックして "コードのカスタマイズ"を選択し、コンボボックスで "カスタム作成"を選択します。ここで新しいjavax.swing.JPanelが作成され、そのサブクラスが置換されます。

だから、フォームに直接ではなく、コンポーネントを適切に操作してペイントすることができました。また、パネルのキーリスナーは、フレームキーイベントディスパッチャーを差し込むよりもはるかに巧妙な解決策です。

とにかく、JPanelのpaintComponent（）でappotated JFrameのpaint（）と同じカスタム塗りつぶしコードがほぼ同じ速度で実行されると、誰かがなぜ説明できるのか不思議でした。

ありがとうございます。キース。

---

EDIT：この質問は誤解メトリックに基づいています。プロファイラは、JPanelのpaintComponent（）メソッドをAWT-EventQueueスレッドにインクルード/レポートしません。ここで、ベースラインプロファイルにはJFrameのpaint（）が含まれています。私は愚かな質問をする前にもっと慎重に見ていたはずです。私の悪い。

Answer 1

"Swingは描画にJava2D APIを使用しており、このJava SE 7のトラブルシューティングガイドに従って、「プリミティブをレンダリングするさまざまな方法としておおまかに定義できる」レンダリングパイプラインのセットを使用します。 Java2Dレンダリングパイプラインは、クロスプラットフォームのJavaコードをハードウェアアクセラレーションをサポートするネイティブグラフィックスライブラリ（OpenGL、X11、D3D、DirectDraw、GDI）に接続するように見える。

Java 1.6.0_10（別名6u10）では、 SwingおよびJava2Dアプリケーションでレンダリングのパフォーマンスを向上させるために、Windows用Java2DにDirect3Dに基づく「アクセラレーションされたグラフィックスパイプライン」が追加されました（デフォルトで有効）。

デフォルトでは、 Java2DがWindowsシステムで使用されている場合、このDirect3DパイプラインとDirectDraw/GDIパイプラインの両方がデフォルトで有効になっています（それぞれ異なるものに使用されていると仮定しています）。上

読む：First call to JFrame constructor takes a long time during Swing application startup (because of java.awt.Window())

Answer 2

のJFrameがJPanelのは、UIスレッド自体によってレンダリングされるスイング構成要素であるのに対し、描画用のネイティブリソースを必要aw.Frameに延びる最上位のコンテナです。