Swing [Umfrage] Swing Performance

[hdi]

Hey,

Ich hatte diesbezüglich bereits vor etwa 2 Jahren ein Topic aufgemacht, allerdings gab es dazu nur 3 Antworten (die mir das auch nicht erklären konnten) und scheinbar kein Diskussionsbedarf..

Es geht um die Performance von Swing, genauer um das Resize eines JFrames, welches bei mir noch nie flüssig funktioniert hat, selbst bei einfachsten GUIs. Es ist lächerlich langsam im Repaint. Man findet man im Netz irgendwie nicht sonderlich viel dazu, und ich kann mir das nicht erklären, denn ich find das extrem störend und es würd mich wundern wenn ich da der einzige bin. Ich möchte mit dieser Umfrage endlich herausfinden ob ihr das kennt oder nicht.

Kuckt euch bitte folgendes Video an:
MEGAUPLOAD - The leading online storage and file delivery service

Sorry für OCH, hab grad kein direkten Webspace dafür übrig.

Dieses Verhalten habe ich schon immer gehabt:
- Windows XP (x86), Vista & 7 (x86 und x64)
- nVidia GeForce 8800GTX, GTX260, GTX580

Stimmt dann bitte ab ob das bei euch auch so ist. Wenn jemand dazu irgendetwas weiß, immer her damit! Wenn das tatsächlich an Swing liegt, bzw. an einer Kombination aus Windows/nVidia und Swing dann muss ich wohl doch auf SWT umsteigen, weil das sieht einfach nur sch** und unprofessionell aus. Mir ist bisher kein Programm untergekommen wo das so war, außer bei meinen Swing Apps.

Ich hab bisher nur rausgefunden dass es evtl was mit dem Aero Theme von Windows zu tun haben könnte. Aber wenn ich den ausschalte ist es eig. genauso, nur dass der Hintergrund beim REsize dann nicht schwarz ist sondern grau.. Ändert nix daran dass es einfach viel zu lange dauert so ein simples Fensterchen mit so wenig Komponenten und solch einem primitiven Layout flüssig malen zu können

Ich hoffe ihr könnt mich da aufklären! Danke für eure Mühen & Abstimmung!

 

[mvitz]

Und für die Faulen hier der Code für Copy&Paste

import java.awt.GridLayout;

import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.SwingUtilities;

public class Test {

    public static void main(String[] args) {
        SwingUtilities.invokeLater(new Runnable() {

            @Override
            public void run() {
                JFrame f = new JFrame();
                f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

                f.setLayout(new GridLayout(3, 3));
                for (int i = 0; i < 9; i++) {
                    f.add(new JButton("X"));
                }

                f.pack();
                f.setLocationRelativeTo(null);
                f.setVisible(true);
            }
        });
    }

}

 

[hdi]

Ja genau, sorry. Ich dachte ohne Video kommt vllt eh nicht rüber was ich meine. Die Frage ist ob euer Frame flüssig repainted beim Resize oder ob ihr zeitweise schwarze/graue Balken seht und man sieht dass der mit dem Repaint bzw Layout nicht in Echtzeit hinterherkommt.

 

[HoaX]

Bei mir geht es super schnell. Wenn ich ein Video von aufnehme dann fängts an zu ruckeln und ich habe ähnliche Effekte. Aber so im normalen Betrieb habe und hatte ich noch nie solche Probleme.

 

[jgh]

wenn ich schnell genug resize, kann ich so ein Verhalten auch bei OpenOffice entdecken, ebenso auch im Texnic-Center. Keine Frage unter swing ist es noch auffälliger.

Finde ich allerdings nicht so sonderlich störend, denn eigentlich resize ich den Frame nur 1x und dann sollte es ja auch passen.

 

[eRaaaa]

Also ich kreuze da jetzt gar nichts an, weil eig. nichts von all dem passt
Ich verstehe eig. eh nicht wieso das (bei Windows?!) so implementiert wurde, wieso muss der Inhalt während des resize neugezeichnet werden? Meiner Meinung reicht es aus, das nach dem fertigen resize (Maustaste losgelassen oder wie auch immer) neu zu zeichnen. So wirds eig. auch bei mir gemacht, vorher sehe ich halt nur die Rahmengröße (siehe Screenshot), mehr brauche ich ja meist eig. auch nicht ?!

 

[homer65]

Konnte bisher keine Probleme feststellen. Habe derzeit Debian 6 (Squeeze) im Einsatz.

 

[Gossi]

Wenn ich mir das Testergebnis so ansehe, scheint es was mit Win 7 zu tun haben ^^

 

[Fab1]

Wenn ich mir das Testergebnis so ansehe, scheint es was mit Win 7 zu tun haben ^^

Kann man trotz des Ergebnisses jetzt nicht direkt sagen. Die meisten besitzen nun mal Win7.

Bei mir tritt das Problem auch auf, noch deutlicher wie bei dir, wie ich finde. Vielleicht täuscht es aber auch. Natürlich auch Win7 :bahnhof:

 

[schlingel]

Ja, das Problem kenne ich auch. Warum dem so ist, kann ich dir leider nicht erklären.

Ich verstehe eig. eh nicht wieso das (bei Windows?!) so implementiert wurde, wieso muss der Inhalt während des resize neugezeichnet werden? Meiner Meinung reicht es aus, das nach dem fertigen resize (Maustaste losgelassen oder wie auch immer) neu zu zeichnen.

Das war eine Look&Feel-Entscheidung. Wenn es funktioniert ist es ja auch ganz nett. Man kann es allerdings auch deaktivieren wenn man das nicht möchte.

 

[hdi]

Ok, scheint als wäre es wirklich ein Swing-Problem in Verbindung mit Windows. Ich hatte ja gehofft dass sich in 1.7 was dran ändert. Imho müssen die Jungs da noch einiges verbessern. Auch an den Layout-Managern. Es gibt zu wenige (FlowLayout.VERTICAL??) und teilweise verhält sich das Layout sehr komisch beim Resize. Bzgl dieser Sache hier hab ich jetzt noch etwas gegooglet, und es gibt Bug Tickets seit 2007, die solche Probleme beschreiben. Bin ich dir denn einzige, der sowas wichtig findet? Naja, sieht also so aus als müsste ich auf SWT umsteigen. Auch wenn ich da die API und Architektur lange nicht so gut finde wie die in Swing.

Könnte sich derjenige, bei dem das unter Win Vista/7 flüssig läuft nochmal zu Wort melden? Vllt Dekstop-Einstlelungen (Aero?) und Grafikkarten-Treiber.

 

[Spacerat]

Ungetestet: Könnte es an Direct3D liegen? Kann man das unter Windows nicht deaktivieren? Unter Windows kann man ja mal einiges ausprobieren.

 

[hdi]

Also am D3D lag's nicht, aber danke für den Link, ich werd die Dinge mal durchtesten!

 

[...ButAlive]

Bei mir mit Fedora 15 kann ich den Effekt auch nicht feststellen. Mal ein Schuss ins Blaue, probier mal nimbus als Look&Feel, das basiert auf 2D Vektor Graphiken und könnte eventuell dadurch schneller Größenänderungen rendern.

 

[hdi]

Danke für den Tipp, hab aber bereits alle (out-of-the-box) L&Fs durchprobiert. Ist leider immer das selbe Komisch, dass man sich dem noch nicht angenommen hat. Je länger ich mich durch die Bug Tickets wühle, desto mehr finde über dieses Verhalten, teils Tickets von vor einigen Jahren.. Und überall ist es Windows.

Übrigens: Wie schaut's eigentlich derzeit mit JFrame#setMinmumSize() aus? Das war doch auch immer so ne Sache.. Bei mir unter Win 7 x64 funktioniert es - kann mich aber daran erinnern dass es früher noch nicht funktioniert hat. In der Doc steht nur "platform dependant". Tja, manchmal verflucht man diese Plattformunabhängigkeit halt doch

 

[winSharp93]

Hallo zusammen,

bei mir tritt das Phänomen ebenfalls auf (Win7 64bit, NVIDIA-Karte).

Allerdings ist es bei mir nicht Java- (oder Swing-) spezifisch; wenn man genau hinschaut tritt das Problem selbst bei WPF-Anwendungen (MS Technologie zum hardwarebeschleunigten Zeichnen von GUIs) auf. Dort allerdings deutlich schwächer (man muss schon sehr genau hinschauen).
Ändert man den Look&Feel in Swing auf "Motif", kann man die schwarzen Balken kaum noch erkennen - vorhanden sind sie aber dennoch.

Unter OSX (Intel-Chipsatzkarte) scheint das Problem hingegen tatsächlich nicht aufzutreten - ich persönlich erkenne jedenfalls keinerlei Balken (und wenn, dann wären diese definitiv nicht schwarz).
Interessant wäre jetzt aber noch ein OSX-System mit NVIDIA-Karte - evtl. liegt es ja daran.

Insofern scheint es wohl nicht direkt an Swing zu liegen, wohl aber durch die langsame Zeichengeschwindigkeit im Standardtheme begünstigt zu werden.

Um ehrlich zu sein, hat mich dieses Phänomen allerdings noch nie groß gestört - man muss ja förmlich danach suchen, um es als Problem zu erkennen ;-)

 

[escalate]

Ich habe das Beispiel mal getestet; es läuft nicht perfekt, aber schon sehr flüssig und deutlich weniger hässlich als in dem Video. Ist vergleichbar zu meinen PyQt-Programmen, also eher keine Swing-spezifischen Aufälligkeiten.

Selbst habe ich mit Swing noch nicht viel gemacht; zufälligerweise habe ich gestern ein wenig mit Scala Swing herumprobiert.

Da ist mir nur aufgefallen, dass das Metal-LnF ziemlich schnell ist, Nimbus sehr ruckelig und insgesamt viel langsamer ist, während GTK-LnF so in etwa in der Mitte liegt.

System:
Linux 3.0
AMD A8-3850 (4x.2.9GHz)
AMD Fusion-Grafik mit fglrx-Treiber 11.9

 

[Guybrush Threepwood]

Hast Du Java 6 oder Java 7? Das Programmbeispiel lässt bei mir (Win7, 64Bit, Java7) gelegentlich einen kleinen, schwarzen Rand erahnen, allerdings nichts, was nicht auch bei anderen Programmen auftreten würde. In komplexeren, also verschachtelten GUIs ist der schwarze Bereich bei mir häufiger zu sehen, aber wirklich stören tut das nicht, oder? Meistens klicken die Leute auf "maximieren" und das wars. Da bekommt man das Artefakt nicht besonders häufig zu sehen.

 

[thE_29]

java.awt.Toolkit.getDefaultToolkit().setDynamicLayout(false);

Und schon wird nix mehr neugezeichnet, wenn man resized!

Ist zwar sicher nicht die beste Methode, aber wenn einen das so stört...


Kommentar aus der Doku:

Controls whether the layout of Containers is validated dynamically during resizing, or statically, after resizing is complete. Note that this feature is not supported on all platforms, and conversely, that this feature cannot be turned off on some platforms. On platforms where dynamic layout during resize is not supported (or is always supported), setting this property has no effect. Note that this feature can be set or unset as a property of the operating system or window manager on some platforms. On such platforms, the dynamic resize property must be set at the operating system or window manager level before this method can take effect. This method does not change the underlying operating system or window manager support or settings. The OS/WM support can be queried using getDesktopProperty("awt.dynamicLayoutSupported").

 

[GUI-Programmer]

Bei mir läuft das Beispeil perfekt! (Java 7)

Mein System:
Windows 7 Home Premium 64Bit
Intel(R) Core(TM) i5 CPU 650 @ 3.20GHz
ATI Radeon HD 5700 Series (2747 MB Grafikspeicher)

 

[ThreadPool]

Bei mir hängt das mit dem verwendeten Windows Theme zusammen. Ich habe Win7 und verwende Java SE6. Wenn ich das Beispiel auf dem Windows 7 - Aero laufen lasse sehe ich diese schwarzen Leerflächen wenn ich sehr schnell die Größe ändere. Dieses "Ausfressen" taucht jedoch nicht auf. Bei Windows 7 - Basis (non Aero) ist die schwarze Fläche wesentlich kleiner als beim Aero - Theme. Verwende ich das Basistheme Windows klassisch sehe ich überhaupt keine schwarzen Flächen mehr bei der Größenänderung. Letzteres ist meine Standardeinstellung.

 

[thE_29]

Weil es eben auf den WindowManager ankommt..

Siehe auch meinen Auszug aus der JavaDoc auf der vorigen Seite... Dieses ganze Resize-Verhalten ist WM abhängig..

 

[hdi]

Hey,

kurzes Update:

-Dsun.java2d.d3d=false

funktioniert doch! Zumindest bei meiner jetzigen Anwendung. Ich weiß nicht ob ich mich vertippt hatte als ich das das letzte mal probiert habe (siehe früherer Post in diesem Thread), oder ob es auf Grund der konkreten Anwendung einfach nichts gebracht hat.

Aber bei der jetzige Anwendung macht es einen deutlichen Unterschied. Die Ränder sind noch immer kurzzeitig schwarz, aber nur in einem Bereich von etwa 10-20 pixel, und das Layout wird in realtime durchgeführt. Im Vergleich: Ohne dieses Flag repainted sich die GUI oft für knapp 1 ganze Sekunde(!) lang nicht und besteht bei großen Resizes zu 80% aus schwarzer Fläche. Das Problem ist also nicht zu 100% eliminiert, aber weitestgehend.

An dieser Stelle also nochmal danke an Spacerat für diesen Vorschlag! Ich würd mich freuen wenn ein paar Leute mit Win Vista/7 und Aero Theme (ich bin mir inzwischen sicher dass es daran liegt) den Unterschied zwischen d3d true und false auch mal testen könnten mit einer möglichst komplexen GUI.

PS @the_29:

java.awt.Toolkit.getDefaultToolkit().setDynamicLayout(false);
Und schon wird nix mehr neugezeichnet, wenn man resized!

Deinen Beitrag hatte ich damals nicht verstanden. Damit verstärkt man das Problem doch weiter, und zwar so krass wie es nur irgendwie möglich ist. Es geht ja genau darum ein flüssiges Repaint/Layout ohne schwarzen Hintergrund zu erzeugen. Oder versteh ich das falsch? Also bei mir bleibt das Fenster in dem Fall so lange komplett schwarz (bzw der neue Bereich, der durch das Resize entsteht) bis ich die Maus loslasse.

 

[GUI-Programmer]

Ich hatte ja geschrieben, dass bei mir nichts ist. Aber als ichs jezt noch ein paar mal probiert habe und ganz ganau hingeschaut habe, hab ichs doch festgestellt. Allerdings mit

-Dsun.java2d.d3d=false

ist bei mir wirklich gar kein schwarzer Rand zu sehen beim Resizen.

Doch, da es hier schon ums Resizen geht, mal ne Frage zu Java in Kombination mit Windows7:
Wird es vielleicht in Zukunft, demnächst, möglich sein, dass auf das Vorschlag-Resizeverhalten von Windows 7 reagiert wird, und das Layout angepasst werden kann. Siehe Bild Resizevorschlag und Bild ResizeAngenommen

 

[Spacerat]

Nochmal ausgegraben? Musste mich erst mal wieder einlesen... Dabei fiel mir auf... Kann es sein, dass nicht unbedingt nur das Beriebsystem dafür verantwortlich ist, sondern auch die unterschiedlichen 2D-Leistungen diverser Grafikkarten? Würde mich mal interessieren, wer von denen, bei denen das auch schwarze Ränder zu sehen sind, keine NVidia-GraKa besitzt.

 

[hdi]

Ja, das wäre auch interessant. Ich hab zumindest ne nVidia.

@GUI Programmer hast für ne Graka hast du?

Doch, da es hier schon ums Resizen geht, mal ne Frage zu Java in Kombination mit Windows7:
Wird es vielleicht in Zukunft, demnächst, möglich sein, dass auf das Vorschlag-Resizeverhalten von Windows 7 reagiert wird, und das Layout angepasst werden kann.

Grundsätzlich ist das schon implementiert. Es handelt sich hierbei nur um einen Bug, der aber nur genau in diesem Fall auftritt, also wenn das Fenster nur vertikal maximiert werden soll. Wenn du das gesamte Fenster an den oberen Rand schiebst, und der Vorschlag ein komplettes Maximize ist, funktioniert das auch.

 

[jDennis79]

Phänomen unter Fedora 16 / KDE 4.7 / AMD RS780 ebenfalls nicht reproduzierbar.

 

[Paddelpirat]

Also auf meinem Notebook (wahlweise Intel HD oder Radeon 5470) hab ich auch noch bei deinem Beispielprogramm schwarze Balken beim größer ziehen. Sogar recht auffällig, dabei ist es egal ob

-Dsun.java2d.d3d=false

verwendet wird oder nicht. Ich meine mich zu erinnern, dass aber eh standardmäßig die opengl Pipe genutzt wird.

Schöner sieht bei mir das Ergebnis mit JavaFX 2.0 aus. Falls mal wer ausprobieren möchte, hier der Code:

package javafxapplication1;

import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.BorderPane;
import javafx.scene.layout.GridPane;
import javafx.scene.layout.Priority;
import javafx.stage.Stage;

/**
 *
 */
public class JavaFXApplication1 extends Application {

    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) {
        launch(args);
    }
    
    @Override
    public void start(Stage primaryStage) {
        primaryStage.setTitle("Hello World!");
        
        BorderPane bPane = new BorderPane();
        
        GridPane gPane = new GridPane();
        for(int i=0; i<3; i++) {
            for(int j=0; j<3; j++) {
                Button b = new Button("X");
                b.setMaxWidth(Double.MAX_VALUE);
                b.setMaxHeight(Double.MAX_VALUE);

                GridPane.setHgrow(b, Priority.ALWAYS);
                GridPane.setVgrow(b, Priority.ALWAYS);

                gPane.add(b, i, j,1,1);
            }
        }
        
        bPane.setCenter(gPane);

        primaryStage.setScene(new Scene(bPane, 300, 300));
        primaryStage.show();
    }
}