>> Echt? SWT Hardwarebeschleungt? Wenn SWT wie AWT eine Peer
>> (OSGUIObjekt-Platzhalter - Technik ist?
> Nun, gerade deshalb kann ja dann der native Peer die beschleunigten
> Treiber nach Belieben nutzen. Und das tun die sicher, wozu hat das OS
> sonst die Treiberschnittstelle? Ein emuliertes Fenster, das zunächst
> eine Linie zeichnet, indem es in Java die Punkte einzeln setzt, müßte
> hingegen so umgeschrieben werden, daß es stattdessen eine "draw
> line"-Funktion des Systems darunter aufruft. Usw. usf. für immer mehr
> Spezialaufgaben, die auch hardwarebeschleunigt werden. Das hat man
> denn auch im Laufe der Zeit gemacht, während die nativen Controls
> schon immer direkten Zugriff auf die Systemschnittstellen hatten.
Ich meinte schlicht Hardwarebeschleunigung Graphik - also direkte
Benutzung von GPU. Bei einer modernen GPU gibt es keinen Unterschied
zwischen 2D und 3D bzw, OpenGl sowie DirectX bieten auch 2D -
Funktionen und alles ist dann von der GPU in Harware gegossen bzw.
kann über Shading/Vertex Languages programmiert werden.
> Vielleicht meinst Du aber, daß irgendein natives Panel nicht
> notwendig auch 3D-Funktionen nutzt und unterstützt.
Genau....Bei Apple ist das so: Die gesammte (2D) Oberfläche von OSX
wird von der Quartz-Engine (Bibliothek) gerendert und Quartz baut auf
OpenGL auf.
Bei Windows ist es so: Obwohl Windows seit langem DirectX ist,
welches übrigens auf Silicon Graphics (SGI) - also auf OpenGL Know
How basiert, wird Windows XP von der antiken und unsäglichen GDI+
Bibliothek gerendert, die ist NICHT hardwarebeschleunigt. Bei Linux
kommt es auf die Benutzeroberflache an: Ist es Gnome, dann GTK, ist
es KDE dann QT, ist es das Fvwm, dann dürfte es Motif sein - alle
zusammen basieren auf x11, das nur bei Apple letztlich
Harwarebeschleunugt ist - OSX ist ja auch Unix.
> Die meisten
> nativen Controls brauchen das ja nicht. Direkt D3D- oder OpenGL-Calls
> nutzen können native Programme, die native Controls öffnen, zwar
> immer. Aber auf der Java-Seite von SWT-Controls gibt es keine
> Abbildung dieser APIs, d.h. 3D-Beschleunigung ist erstmal kein Thema.
Doch, weil man bei OpenGL alle Funktionen auch als 2D Funktionen hat,
wie "zeichne eine 2d Linie" hat. Du kannst sogar Punkte malen - also
sogar 1D Funktionen - Hardware&GPU-Beschleunigt (-; Bei OpenGL ist
z.B ein Punkt so definiert: glVertex3d(x,y,z); oder glVertex2d(x,y);
also einmal als 2D Punkt und einmal als 3D Punkt.
> Da existierende APIs sich auf AWT/Swing beziehen, müßte man für SWT
> erst mal auch ein javaseitiges 3D-Support-API definieren und diese
> Bindings implementieren. Was ja auf der anderen Seite mit Java3D,
> Jogl u.ä. schon existiert.
Genau dies hatte man beim Wechsel von Java 1.3 zu 1.4 getan, nämlich
eine vernünftige Renderengine mit Stack-Architektur zu entwickeln,
die man auf OpenGL mappen kann. Anstatt also wie mit der AWT/SWT
OSGUI-Objekt-Peer-Technik einfach OSGUI-Objekte wie komplette Buttons
einzuspannen, wobei Java als Platzhalter fungiert, ist SWING soweit
es geht (irgendwann fängt irgendwo immer das OS an - z.B. im Bereich
WindowManager oder Images) 100% Java mit 100% Java-Graphik-Engine,
ABER bei eingeschalteter Harware-GPU-Beschleunigung wird dann OpenGL
eingespannt, Java wieder als Platzhalter dienend. Also wieder
Peer-Technik, nur waren es früher bei AWT/SWT Buttons und Slider und
bei SWING soll es OpenGL sein - man will so flexibler beim Portieren
werden - es gibt nur ein OpenGL aber viele WindowsOSGUI Bibliotheken,
für die immer beim Portieren eine Extrawurst gebraten werden müssen.
Der Unterschied wird dann so sein: AWT/SWT - Funktion "updateImage"
wird direkt an ImageObjekt der Betriebssystem GUI Bibliothek
delegiert: Bei Windows XP dann letztlich also GDI+Funktion
"updateImage".
SWING: - Funktion "updateImage" wird als ein ganzes Set von
Graphikbefehlen an OpenGL geschickt - so soll es mal werden bei
SWING.
>> (OSGUIObjekt-Platzhalter - Technik ist?
> Nun, gerade deshalb kann ja dann der native Peer die beschleunigten
> Treiber nach Belieben nutzen. Und das tun die sicher, wozu hat das OS
> sonst die Treiberschnittstelle? Ein emuliertes Fenster, das zunächst
> eine Linie zeichnet, indem es in Java die Punkte einzeln setzt, müßte
> hingegen so umgeschrieben werden, daß es stattdessen eine "draw
> line"-Funktion des Systems darunter aufruft. Usw. usf. für immer mehr
> Spezialaufgaben, die auch hardwarebeschleunigt werden. Das hat man
> denn auch im Laufe der Zeit gemacht, während die nativen Controls
> schon immer direkten Zugriff auf die Systemschnittstellen hatten.
Ich meinte schlicht Hardwarebeschleunigung Graphik - also direkte
Benutzung von GPU. Bei einer modernen GPU gibt es keinen Unterschied
zwischen 2D und 3D bzw, OpenGl sowie DirectX bieten auch 2D -
Funktionen und alles ist dann von der GPU in Harware gegossen bzw.
kann über Shading/Vertex Languages programmiert werden.
> Vielleicht meinst Du aber, daß irgendein natives Panel nicht
> notwendig auch 3D-Funktionen nutzt und unterstützt.
Genau....Bei Apple ist das so: Die gesammte (2D) Oberfläche von OSX
wird von der Quartz-Engine (Bibliothek) gerendert und Quartz baut auf
OpenGL auf.
Bei Windows ist es so: Obwohl Windows seit langem DirectX ist,
welches übrigens auf Silicon Graphics (SGI) - also auf OpenGL Know
How basiert, wird Windows XP von der antiken und unsäglichen GDI+
Bibliothek gerendert, die ist NICHT hardwarebeschleunigt. Bei Linux
kommt es auf die Benutzeroberflache an: Ist es Gnome, dann GTK, ist
es KDE dann QT, ist es das Fvwm, dann dürfte es Motif sein - alle
zusammen basieren auf x11, das nur bei Apple letztlich
Harwarebeschleunugt ist - OSX ist ja auch Unix.
> Die meisten
> nativen Controls brauchen das ja nicht. Direkt D3D- oder OpenGL-Calls
> nutzen können native Programme, die native Controls öffnen, zwar
> immer. Aber auf der Java-Seite von SWT-Controls gibt es keine
> Abbildung dieser APIs, d.h. 3D-Beschleunigung ist erstmal kein Thema.
Doch, weil man bei OpenGL alle Funktionen auch als 2D Funktionen hat,
wie "zeichne eine 2d Linie" hat. Du kannst sogar Punkte malen - also
sogar 1D Funktionen - Hardware&GPU-Beschleunigt (-; Bei OpenGL ist
z.B ein Punkt so definiert: glVertex3d(x,y,z); oder glVertex2d(x,y);
also einmal als 2D Punkt und einmal als 3D Punkt.
> Da existierende APIs sich auf AWT/Swing beziehen, müßte man für SWT
> erst mal auch ein javaseitiges 3D-Support-API definieren und diese
> Bindings implementieren. Was ja auf der anderen Seite mit Java3D,
> Jogl u.ä. schon existiert.
Genau dies hatte man beim Wechsel von Java 1.3 zu 1.4 getan, nämlich
eine vernünftige Renderengine mit Stack-Architektur zu entwickeln,
die man auf OpenGL mappen kann. Anstatt also wie mit der AWT/SWT
OSGUI-Objekt-Peer-Technik einfach OSGUI-Objekte wie komplette Buttons
einzuspannen, wobei Java als Platzhalter fungiert, ist SWING soweit
es geht (irgendwann fängt irgendwo immer das OS an - z.B. im Bereich
WindowManager oder Images) 100% Java mit 100% Java-Graphik-Engine,
ABER bei eingeschalteter Harware-GPU-Beschleunigung wird dann OpenGL
eingespannt, Java wieder als Platzhalter dienend. Also wieder
Peer-Technik, nur waren es früher bei AWT/SWT Buttons und Slider und
bei SWING soll es OpenGL sein - man will so flexibler beim Portieren
werden - es gibt nur ein OpenGL aber viele WindowsOSGUI Bibliotheken,
für die immer beim Portieren eine Extrawurst gebraten werden müssen.
Der Unterschied wird dann so sein: AWT/SWT - Funktion "updateImage"
wird direkt an ImageObjekt der Betriebssystem GUI Bibliothek
delegiert: Bei Windows XP dann letztlich also GDI+Funktion
"updateImage".
SWING: - Funktion "updateImage" wird als ein ganzes Set von
Graphikbefehlen an OpenGL geschickt - so soll es mal werden bei
SWING.