Endlich Ende der langsamen GUI's?

Ich habe bisher immer mit eclipse 3.0 und Java 1.4.2 gearbeitet. Heute hab ich auf einen Tipp von einem Kollegen 1.5 und netbeans 4.0 installiert.

Ich kann einfach nur sagen

netbeans merkt man nicht an das es in Swing geschrieben wurde. Ich merke auf einem 2 GHz. P4 keinen Unterschied zu Nativ IDE's!

Ist es euch auch aufgefallen? Liegt das daran das die Jungs von Sun genial programmieren können, oder an 1.5?

Artchi

Traurig das erst bei 2 GHz (hallo?! 2 GHz!!!) eine GUI nicht mehr langsam ist.

Trollbeitrag...

elise

Turbo-Swing schrieb:

die Jungs von Sun

einseitige sichtweise.

elise schrieb:

Turbo-Swing schrieb:

die Jungs von Sun

einseitige sichtweise.

Natürlich auch die Mädels!

Artchi schrieb:

Traurig das erst bei 2 GHz (hallo?! 2 GHz!!!) eine GUI nicht mehr langsam ist.

Ich hab nicht gesagt, daß es darunter noch langsam ist. Ich weiß nur das 1.4.2 plus eclipse auf dieser Kiste lahm waren.

Aber wenn du das so siehst, dann haben doch Sun und co. recht. Bald hat jeder nen 3 GHz Rechner und dann interessiert der unterschied eh keine Sau mehr.

Artchi schrieb:

Traurig das erst bei 2 GHz (hallo?! 2 GHz!!!) eine GUI nicht mehr langsam ist.

Swing ist inzwischen völlig benutzbar geworden. Was gibt's da überhaupt zu kritisieren?
Java hat wenigstens ein GUI-API, ein sehr flexibles und plattformunabhängiges, zusätzlich zu der Möglichkeit, native Funktionen des Betriebssystems zu nutzen.

@Turbo-Swing: Es gibt zur Zeit Pläne, Swing-GUIs in Zukunft mit OpenGL zu rendern. Spätestens dann ist dein Name gerechtfertigt.

Was soll OpenGL bringen? Da liegt doch nicht der Flaschenhals.

Wo denn deiner Meinung nach dann? Native GUIs werden hardwarebeschleunigt gerendert, Swing im Moment kaum bis gar nicht.

Swing wird doch unter Windows im Endeffekt das GDI benutzen. Und das ist ja wohl schnell genug.

net 0

flasche schrieb:

Swing wird doch unter Windows im Endeffekt das GDI benutzen. Und das ist ja wohl schnell genug.

ja, aber swing benutzt nur ein paar ultra-primitive malfunktionen, keine vorgefertigten controls (wie awt z.b). vorteil dabei ist, dass es auf allen systemen gleich aussieht (naja, jedenfalls aussehen soll), look-and-feel skins hat usw...

btw: mehr auf's gdi zurechtgeschnitten ist das: http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html

flasche schrieb:

Swing wird doch unter Windows im Endeffekt das GDI benutzen. Und das ist ja wohl schnell genug.

gdi soll schnell sein???
k, dann werd ich mal eben quake 4 mit gdi schreiben!!!!111einseinself

ichbinsgewesen schrieb:

flasche schrieb:

Swing wird doch unter Windows im Endeffekt das GDI benutzen. Und das ist ja wohl schnell genug.

gdi soll schnell sein???
k, dann werd ich mal eben quake 4 mit gdi schreiben!!!!111einseinself

dumm???????ßßßßßßßßß

GDI ist saulahm, das ist doch der Punkt. Das wirst du spätestens dann zu spüren bekommen, wenn du ein paar AffineTransformationOp Objekte auf dein BufferedImage mit Bilinearer Filterung anwendest und das resultierende Bild dann im Frame anzeigst - alles Software-gerendert.

net schrieb:

btw: mehr auf's gdi zurechtgeschnitten ist das: http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html

Höh? Inwiefern ist das auf das GDI zugeschnitten? SWT benutzt ja genau nicht das GDI, um seine Elemente zu zeichnen, sondern benutzt native Widgets.

aber die nativen gui elemente von windows benutzen doch auch gdi und sind schnell.
also liegt es an java und nicht daran welche grafikschnittstelle zur ausgabe benutzt wird.

Nein, die benutzen nicht das GDI. Das GDI kann nur auf den nativen Widgets malen.

Wie in jeder Diskussion: Die Leute die eine Sprache nicht mögen kennen sie meistens auch nicht. Dann kommen solche Vermutungen.

Wie Optimizer schon schrieb: SWT benutzt native Widgets und Swing das GDI.

Ich sehe auch das Problem nicht? Die Zeiten wo man mit Assembler programmieren muss damit man alles aus dem x86 mit 33 MHz und 4 MB RAM alles rausholen muss sind vorbei. Auf heutigen modernen PC's(>= 2GHz, 512++ RAM) läuft Java flüssig, falls keine Programmierfehler vorhanden sind.

In Zukunft werden wahrscheinlich die Rechner auch nicht wieder langsamer.

Also wo ist euer Problem?

Wie sagt man in unserer Branche: Entwicklungskosten sind höher als Hardware kosten. Dieser Satz erklärt auch ganz gut den Erfolg von Java und C#.

Optimizer schrieb:

Nein, die benutzen nicht das GDI. Das GDI kann nur auf den nativen Widgets malen.

Du willst also sagen die in Windows erhaltenen Steuerelemente wie Button, Static, ListBox, ListView etc. benutzen nicht GDI?

Ich will's nicht nur sagen, ich habe es gesagt.
Mit dem GDI kriegst du ja ein GraphicsContext, auf den Widgets, worauf du dann malen kannst.

ich verstehe das nicht, ist auch egal.
jedenfalls benutzen die windows-steuerelemente das gdi. kannst ja mal in den quelltext schauen.

net 0

Optimizer schrieb:

net schrieb:

btw: mehr auf's gdi zurechtgeschnitten ist das: http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html

Höh? Inwiefern ist das auf das GDI zugeschnitten? SWT benutzt ja genau nicht das GDI, um seine Elemente zu zeichnen, sondern benutzt native Widgets.

ich meinte mehr auf windows zugeschnitten und deshalb flinker als swing