Meine Frage ist: WARUM ist die gleiche Swing-Custom-Painting-Routine beim Zeichnen auf JPanel fast 16-mal schneller als direkt auf dem JFrame? Ist es nur doppelt gepuffert? Es kann nicht sein, sicher?
Hintergrund: Ich hatte ein Problem damit, dass das benutzerdefinierte Bild nicht aktualisiert wurde, wenn der JFrame ungehindert war (besonders wenn er nur teilweise verdeckt wurde). Nach der Suche nach SO entschied ich mich, die Kugel zu durchtrennen und herauszufinden, wie man eine Unterklasse von JPanel in eine Bluddy-NetBeans-Formular-Designer-Form bringt.
Für jeden in der gleichen Situation: In NetBeans müssen Sie eine neue Standardklasse erstellen (NICHT ein JPanel-Formular), die einfach JPanel erweitert und alles manuell einprogrammiert (kein GUI-Designer, wie der gute Ole -Tage, Seufzer). Dann fügen Sie Ihrem Formular ein Standard-JPanel hinzu, legen Sie dessen Größe fest; dann mit der rechten Maustaste und wählen Sie "Customize code" und wählen Sie "custom creation" in der Combo-Box ... wo es ein neues javax.swing.JPanel ersetze Ihre Unterklasse davon.
Also ... Das erlaubte mir, "es richtig zu machen" und auf eine Komponente zu malen, anstatt direkt auf das Formular. Auch der Panels-Key-Listener ist eine viel bessere Lösung, als den Frames Key-Event-Dispatcher zu überlisten.
Wie auch immer, jetzt sagt der Profiler, dass GENAU derselbe benutzerdefinierte Zeichencode fast 16 Mal schneller in JPanels paintComponent () als JFrames Farbe () ausgeführt wird ... und ich fragte mich, ob irgendjemand bitte erklären könnte, warum.
Vielen Dank im Voraus. Keith.
BEARBEITEN: Diese Frage basiert auf falsch interpretierten Metriken. Der Profiler enthält nicht die paintComponent () -Methode von JPanel im AWT-EventQueue -Thread, da mein Basisprofil JFrames paint () enthält. Ich hätte besser nachsehen sollen, bevor ich eine dumme Frage gestellt hätte. Mein Schlechter.
JFrame ist ein Container der obersten Ebene, der einen aw.Frame erweitert, der native Ressourcen zum Zeichnen benötigt, während JPanel eine Swing-Komponente ist, die vom UI-Thread selbst gerendert wird.
"Swing verwendet die Java2D-API zum Zeichnen, und Java2D verwendet gemäß dieser Java SE 7-Fehlerbehebungshilfe eine Reihe von Rendering-Pipelines," die grob als unterschiedliche Arten zum Rendern der Primitive definiert werden können. "Genauer gesagt, ein Java2D Rendering-Pipeline scheint plattformübergreifenden Java-Code mit nativen Grafikbibliotheken (OpenGL, X11, D3D, DirectDraw, GDI) zu verbinden, die Hardwarebeschleunigung unterstützen können.
In Java 1.6.0_10 (alias 6u10) wurde Java2D für Windows eine "vollständig hardwarebeschleunigte Grafikpipeline" basierend auf Direct3D hinzugefügt, um die Renderleistung in Swing- und Java2D-Anwendungen zu verbessern (standardmäßig aktiviert).
Wenn Java2D auf einem Windows-System verwendet wird, sind standardmäßig sowohl diese Direct3D-Pipeline als auch eine DirectDraw / GDI-Pipeline standardmäßig aktiviert (ich nehme an, dass sie jeweils für verschiedene Dinge verwendet werden). "
Lesen Sie weiter: Der erste Aufruf des JFrame-Konstruktors dauert beim Start der Swing-Anwendung lange (wegen java.awt.Window ())
Tags und Links java swing custom-painting