GUI : Welche API?
-
Swing ist langsam, weil Java alles selber zeichnen muss,
Qt und GTK zeichnen doch auch alles selbst, wieso sollte da Java langsam sein?
-
DEvent schrieb:
Swing ist langsam, weil Java alles selber zeichnen muss,
Qt und GTK zeichnen doch auch alles selbst, wieso sollte da Java langsam sein?
kann sein dass GTK usw. auch langsam ist (hat nicht wireshark eine GTK GUI? wenn ja: es ist langsam), aber swing-programme zeichnen sich durch eine gewisse trägheit aus. das kennste doch bestimmt.
ist ja nicht so, dass es störend wirkt, aber es fällt nun mal auf...
-
pale dog schrieb:
aber swing-programme zeichnen sich durch eine gewisse trägheit aus. das kennste doch bestimmt.
Das liegt in erster Linie daran, dass Swing von vielen Leuten falsch genutzt wird (wenn zum Beispiel unnötig viel im EDT gemacht wird, weil man keine Lust hat, einen eigenen Thread zu starten). Es ist aber keine prinzipielle Eigenschaft von Swing.
-
Gregor schrieb:
pale dog schrieb:
aber swing-programme zeichnen sich durch eine gewisse trägheit aus. das kennste doch bestimmt.
Das liegt in erster Linie daran, dass Swing von vielen Leuten falsch genutzt wird (wenn zum Beispiel unnötig viel im EDT gemacht wird, weil man keine Lust hat, einen eigenen Thread zu starten). Es ist aber keine prinzipielle Eigenschaft von Swing.
abgesehen davon, das selbermalen kostet nun mal mehr zeit, als wenn man's dem eingebauten grafiksystem überlassen würde. zwar minimal, aber es summiert sich auf. man merkt es z.b. an wireshark und 'the gimp', welche, glaube ich, beide GTK benutzen und daher wirkt die GUI etwas träger als mit einbautem windowing...
-
pale hat wieder ahnung
ich benutz keine gtk programme allein schon weil sie unter windows einfach scheiße aussehen daher kann ich das nicht beurteilen, aber wie gregor schon sagte ist swing *nicht* langsam (da über directx (falls vorhanden) und ansonsten opengl beschleunigt wird). im gegenteil: eher swt ist langsam wie opa, auf allen nicht-windows systemen (von stabilität von denselben will man gar nich anfangen...)
-
doof-detektor schrieb:
ich benutz keine gtk programme allein schon weil sie unter windows einfach scheiße aussehen daher kann ich das nicht beurteilen
du hast ja merkwürdig gründe, programme nicht zu benutzen
doof-detektor schrieb:
aber wie gregor schon sagte ist swing *nicht* langsam.
auf meinen kisten läuft es stokeliger als etwa SWT oder irgenwelche direkt mit wipapi gebastelten GUIs. vielleicht hast du ja so'ne killermaschine wo's nicht auffällt?
-
pale dog schrieb:
auf meinen kisten läuft es stokeliger als etwa SWT oder irgenwelche direkt mit wipapi gebastelten GUIs. vielleicht hast du ja so'ne killermaschine wo's nicht auffällt?
Was hast Du denn für nen Rechner? ...auf meinem Rechner laufen WinAPI-GUIs gar nicht.
-
BTW: Um noch mal deutlicher zu machen, welchen Unterschied ich weiter oben meine, kommen hier mal 2 Testprogramme, die beides demonstrieren:
Schlechte Variante:
import javax.swing.*; import java.awt.*; import java.awt.event.*; public class SwingTest1 { public static void main(String[] args) { JFrame frame = new JFrame("Swing Test im EDT"); JButton button = new JButton("Test"); frame.add(button); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); frame.setSize(new Dimension(300,300)); button.addActionListener(new EDTActionListener()); frame.setVisible(true); } private static class EDTActionListener implements ActionListener { public void actionPerformed(ActionEvent e) { for(int i = 0 ; i < 300000 ; ++i) { System.out.println(i); } } } }
Bessere Variante:
import javax.swing.*; import java.awt.*; import java.awt.event.*; public class SwingTest2 { public static void main(String[] args) { JFrame frame = new JFrame("Swing Test im neuen Thread"); JButton button = new JButton("Test"); frame.add(button); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); frame.setSize(new Dimension(300,300)); button.addActionListener(new NewThreadActionListener()); frame.setVisible(true); } private static class NewThreadActionListener implements ActionListener { public void actionPerformed(ActionEvent e) { new WorkerThread().start(); } } private static class WorkerThread extends Thread { public WorkerThread() { setPriority(Thread.MIN_PRIORITY); } public void run() { for(int i = 0 ; i < 300000 ; ++i) { System.out.println(i); } } } }
Normalerweise würde man wohl am Besten den SwingWorker-Mechanismus verwenden. Habe ich hier aber nicht gemacht.
Was hier beim Drücken des Buttons ausgelöst wird, ist natürlich ziemlich zeitaufwändig, so dass der Unterschied sofort offensichtlich wird. Oft hat man da Dinge zu tun, die durchaus schneller zu machen sind. Die kosten aber auch Zeit. Die Frage ist halt, ab wann der Programmierer sich dazu entschließt, den Mehraufwand einzugehen und einen neuen Thread zu starten.
-
Ich würde an deiner Stelle SWT nehmen, da das native GUI-Elemente bietet und damit dem User ein gewohntes Look-and-Feel gibt.
-
rüdiger schrieb:
Ich würde an deiner Stelle SWT nehmen, da das native GUI-Elemente bietet und damit dem User ein gewohntes Look-and-Feel gibt.
Die GUI-Elemente von SWT schränken einen ein. Individualität ist damit nur schwer machbar. Dabei kann man mit etwas Aufwand eine ganze Menge aus irgendwelchen GUIs rausholen.
Siehe da: http://www.curious-creature.org/2006/10/17/screenshots-and-video-of-extreme-gui-makeover-2006/
-
Afaik verliert Java aber (zumindest als "binary") bei benutzung von Swing und SWT
seine vielgerühmte "Plattformunabhängigkeit"...
korrigiert mich bitte, wenn ich da falsch liege, aber seitweit ich weis, bleibt ein Java GUI proggi nur mit AWT noch "binär Plattformunabhängig", ansonsten ist nur noch der Source portabel...
Abgesehen davon dass ich immer ncoh der Meinung bin, dass JAVA nur auf EINER EINZIGEN palttform läuft: der JVM ...
-
JavaSpotter schrieb:
korrigiert mich bitte, wenn ich da falsch liege
Ok
Wenn du mit Swing arbeitest, kannst du den Bytecode von einer Platform auf die nächste kopieren.
Wenn du mit SWT arbeitest, kannst du den Bytecode deines Programmes von einer Platform auf die nächste kopieren, musst aber die SWT-Libraries umtauschen (zumindest die DLLs).