Gedanken zu Swogl :)

[Markus]

Hallo,
ich hab mich in den letzten Tagen ein wenig mit Swogl beschäftigt und schreib hier einfach mal zusammen, auf welche Dinge ich so aufmerksam geworden bin. Gerne kann man das auch in mehrere Threads aufsplitten, wenn es die Diskussion vereinfacht. Über hinweise, wenn ich einfach nur etwas übersehen habe, bin ich auch sehr erfreut

Grundeinstellungen
Eine möglichkeit, in die während des init() vorgenommen Einstelungen eingreifen zu können, z.B. für DebugGL, Antialiasing, Lichteinstellungen (wobei das schon in deinen anderen Thread fällt, oder?)

Camera
Ich denke, ein Camera-Interface, um die Position verändern zu können, etc wäre ganz nützlich.

In der Cameraklasse fehlt, glaub ich, folgene Implementierung der StartMovement Methode:

previousMousePosition = point;

(ohne das Sprint die Sicht, wenn man versucht, in mehreren "Schritten" zu scrollen)

Arrangement Interpolator
Dieser scheint nicht ganz komplett zu sein, ich erhielt hier in der Ergebnismatrix NaN Werte, die dann dazu führten, dass meine Transformation leider nicht das zeigte, was ich erwartete Ganz ergründet hab ich das Problem nicht, da ich dann auf das TimingFramework aufmerksam geworden bin.

Timing Framework
Für meine Animation auf das TimingFramework zurückzugreifen ersparte mir eine Menge Code und erleichterte viel Kennst Du das Framework, hast Du es schonmal angeschaut? Vielleicht würde sich hier eine Verknüpfung mit Swogl anbieten?



Lightweight / Heavyweight (GLCanvas / GLJPanel)

In der derzeitigen Version verwendet JOGL die leightweight Komponente GLJPanel für die OpenGL Darstellung. Dies führt leider dazu, das die Hardwarebeschleunigung für OpenGL (fast?) vollständig verloren geht.

Für die reine Darstellung ist es möglich, das GLJPanel gegen ein GLCanvas zu tauschen, dann werden jedoch die Mausevents nicht mehr richtig an die Swing Componenten weitergereicht. Hier habe ich versucht, genauer nachzuforschen und die Events "per Hand" an die "angeklickte" Swingkomponente zu dispatchen (eigener Layoutmanager3D, der die Events verarbeitet).
Leider bisher ohne abschliessenden Erfolg. Hast Du hier schonmal über eine Möglichkeit, GLCanvas einzusetzen und so die volle Hardwarebeschleunigung zu erhalten, nachgedacht?

Soweit erstmal meine ersten Gedanken

Große Anerkennung auf jeden Fall für die erste Version von Swogl!!

Viele Grüße
Markus

[Marco13]

Erstmal danke für das feedback und die Anregungen

Wenn einzelne dieser Punkte ggf. in eigenen Threads weiterdiskutiert werden, sollte das bevorzugt auf Englisch passieren. Für mich schreibt sich's zwar auch leichter auf Deutsch, aber damit schließt man so viele von der Diskussion aus...


Grundeinstellungen
Ja, das ist bisher noch nicht berücksichtigt. An Dinge wie Antialisaing hatte ich noch nicht gedacht, aber Dinge wie die Lichteinstellungen sind ja schon andeutungsweise umgesetzt - wenn auch bisher nur sehr vorläufig. Ich werde den Vorschlag in den (jetzt verallgemeinerten) Thread http://forum.byte-welt.de/showthread...0266#post10266 aufnehmen.


Camera

Auch die Camera-Klasse ist im Moment als "vorläufig" kommentiert. Sie ist package-private und bietet die grundlegende Funktionalität einer Camera (wenn der Bug, den du erwähnt hast, behoben ist ) aber die ist noch nicht durch ein sauberes Interface nach draußen geroutet. Da müßte man sich mal was überlegen - ich mach' dafür mal einen Thread auf


Arrangement Interpolator

Zugegeben, er ist noch nicht ausführlich getestet (und wir im Moment auch nicht verwendet?) - es kann sogar sein, dass der eher versehentlich schon als öffentliche Klasse mit in die beta gerutscht ist. Ich werde bei Gelegenheit mal nachsehen, WIE beta der wirklich ist ...

Falls das nötig ist...:

Timing Framework

Über das bin ich kürzlich auch gestolpert. Es stimmt, dort werden einige Dinge in schön allgemeiner Form angeboten, und es macht vermutlich keinen Sinn, das ganze in Swogl nochmal in ähnlicher Form nachzubauen... Ich werde mir das mal genauer ansehen, und schauen, ob man das innerhalb des (oder sogar als Ersatz für das) animation package verwenden könnte.


Lightweight / Heavyweight (GLCanvas / GLJPanel)

In der derzeitigen Version verwendet JOGL die leightweight Komponente GLJPanel für die OpenGL Darstellung. Dies führt leider dazu, das die Hardwarebeschleunigung für OpenGL (fast?) vollständig verloren geht.

Hm das wüßte ich jetzt nicht - ich habe zwar bisher keinen direkten Geschwindigkeitsvergleich gemacht, aber auch keinen Unterschied in bezug auf die Geschwindigkeit bemerkt... Aber die Frage ob GLJPanel oder GLCanvas ist ein "heikler" Punkt: Ich hatte ursprünglich auch einen GLCanvas verwendet. Das hat zu einigen Problemen geführt. Dann bin ich zu GLJPanel gewechselt. Das hat auch zu Problemen geführt. Dann noch ein paar mal hin und her aber letztendlich wollte ich eigentlich schon ein (GL)JPanel, weil man in einer Swing-Umgebung eben Lightweight-Components hat - die Probleme beim Mischen von Heavy- und Lightweigt sind ja bekannt, und mit dem GLJPanel werden die vermieden, und auch solche Dinge wie das Event handling sauberer und einfacher. Wie und wo äußert sich denn der Geschwindgkeitsunterschied, oder woher weißt du, dass bei GLJPanel keine Hardwarbeschleunigung erfolgt?

[Markus]

Hi,
ich antworte hier noch zu einem Thema und wechsel sonst mit in die neuen Threads

Zitat von Marco13

Lightweight / Heavyweight (GLCanvas / GLJPanel)

Hm das wüßte ich jetzt nicht - ich habe zwar bisher keinen direkten Geschwindigkeitsvergleich gemacht, aber auch keinen Unterschied in bezug auf die Geschwindigkeit bemerkt... Aber die Frage ob GLJPanel oder GLCanvas ist ein "heikler" Punkt: Ich hatte ursprünglich auch einen GLCanvas verwendet. Das hat zu einigen Problemen geführt. Dann bin ich zu GLJPanel gewechselt. Das hat auch zu Problemen geführt. Dann noch ein paar mal hin und her aber letztendlich wollte ich eigentlich schon ein (GL)JPanel, weil man in einer Swing-Umgebung eben Lightweight-Components hat - die Probleme beim Mischen von Heavy- und Lightweigt sind ja bekannt, und mit dem GLJPanel werden die vermieden, und auch solche Dinge wie das Event handling sauberer und einfacher. Wie und wo äußert sich denn der Geschwindgkeitsunterschied, oder woher weißt du, dass bei GLJPanel keine Hardwarbeschleunigung erfolgt?

Das ganze hab ich in erster Linie aus den Docs zu JOGL. Das beim GLJPanel garkeine Hw-Beschleunigung stattfindet ist wohl nicht so, deswegen hatte ich oben das "fast" in Klammern geschrieben.

In
http://kenai.com/projects/jogl/pages..._a_good_idea_?
und https://jogl.dev.java.net/source/bro...ide/index.html finden sich mehr informationen dazu, unter anderem:

The GLCanvas is a heavyweight AWT widget which supports hardware acceleration and which is intended to be the primary widget used by applications. The GLJPanel is a fully Swing-compatible lightweight widget which supports hardware acceleration but which is not as fast as the GLCanvas because it typically reads back the frame buffer in order to draw it using Java2D.

Diese Performanceunterschiede konnte ich leider auch schon feststellen. In dem aktuellen Userguide steht aber auch, das das GLJPanel deutlich verbessert worden sein soll - vielleicht würde ein wechsel auf JOGL 2 hier den Unterschied verringern.

Was hattest Du denn für Probleme mit dem GLCanvas? Ging es da in erster Linie ums Picking?

Grüße
Markus

[Marco13]

Ja, das hatte ich auch in der Doku zu GLJPanel gelesen: Dort wird wohl (grob gesagt) in PBuffers gerendert, und DIE dann mit Java2D gezeichnet, was nach "einem zusätzlichen Umkopieren" des Bildschirminhalts klingt. Eigentlich sollte das auf die Performance nicht mehr sooo viel Einfluß haben. In der Doku, die du verlinkt hast, steht ja auch, dass das mit neueren Java-Versionen nochmal deutlich beschleunigt wurde.

Aber ein anderer Satz aus der GLJPanel-Doku klingt natürlich beunruhigend: "This component attempts to use hardware-accelerated rendering via pbuffers and falls back on to software rendering if problems occur." - und DAS wäre dann langsam. Das GLJPanel ist aber auch relativ neu, ist glaube ich erst bei JOGL 1.1 dazugekommen, d.h. da ist sicher noch Potential...

Vielleicht hast du ja auf der Wiki-Seite http://code.google.com/p/swogl/wiki/MainPage gesehen, dass schon da einige der schon hier in Threads geflossenen Punkte angedeutet waren (Custom Rendering, Camera... aber alles nur als Anstubser für Diskussionen...), und unter anderem auch die Frage der Portierung nach JOGL 2.0. Aber über den "Status" von JOGL 2.0 findet man nicht so viel - es gibt zwar den Download auf der JOGL-Seite, aber praktisch keine Doku, Release Notes, What's New und so ... Vielleicht sollte man damit noch ein bißchen warten, bis man genauere Infos dazu bekommt.

Das Picking war eines der Probleme mit dem GLCanvas. Wobei ich sagen muss, dass viele dieser Probleme in einem SEHR fürhen Stadium aufgetreten sind, und es gut sein könnte, dass JETZT ein Wechsel auf GLCanvas nicht mehr sooo problematisch wäre. Aber weitere Schwierigkeiten waren z.B. die, die, die VOR dem hier angedeuteten "Test" aufgetreten sind (das war afair die Stelle, wo ich "endgültig" auf GLJPanel gewechselt habe - ist also wirklich schon eine Weile her). Mit dem GLCanvas wurden also auf einigen (hauptsächlich ATI-) Grafikkarten nur graue Flächen angezeigt - aber ob DAS wiederum damit zusammengehongen haben könnte, dass dort die Behandlung der Nicht-Power-Of-2-Texturen noch nicht drin war, weiß ich nicht.
Darüberhinaus das übliche beim Mischen von Heavy- und Lightweight: Dass wenn man ein JMenu vor dem SwoglContainer aufklappen würde, das JMenu per default nicht sichtbar wäre (wenn man es nicht explizit auf Heavyweight schaltet) usw.

Wie gesagt: Ich finde schon, dass der SwoglContainer eine Lightweight-Component sein sollte. geringe Geschwindigkeitseinbußen könnte man dafür wohl hinnehmen (da gäbe es andere Stellen, dan denen man IMHO eher optimieren könnte). Wenn aber wirklich massive Probleme auftreten, könnte man zumindest versuchen, Mechanismen einzuführen, die (ggf. sogar nur zur Compilezeit) ein leichtes "Umschalten" zwischen GLJPanel und GLCanvas erlauben. Die Variable für das GLJpanel trägt nicht umsonst den Namen "glComponent" Zeitweise könnte man da wirklich relativ leicht zwischen GLJPanel und GLCanvas umschalten, aber das war noch zu einer Zeit, wo keins von beidem zufriedenstellend funktioniert hat... Welche Auswirkungen jetzt ein Umschalten auf GLCanvas hätte, weiß ich nicht.

[Marco13]

Vielleicht schwächt sich die Problematik hiermit ja demnächst etwas ab:
http://forum.byte-welt.de/showthread.php?t=2401

[Markus]

Zitat von Marco13

[...] und unter anderem auch die Frage der Portierung nach JOGL 2.0. Aber über den "Status" von JOGL 2.0 findet man nicht so viel - es gibt zwar den Download auf der JOGL-Seite, aber praktisch keine Doku, Release Notes, What's New und so ... Vielleicht sollte man damit noch ein bißchen warten, bis man genauere Infos dazu bekommt.

Ein paar Infos findet man hier zum Beispiel: http://www.javagaming.org/index.php?...&topic=12817.0
Allerdings hast Du recht sind die Beträge dort etwas älter. Ich finde man aber trotzdem Ruhig auf Jogl 2 wecheln sollte

Zitat von Marco13

[...]

Welche Auswirkungen jetzt ein Umschalten auf GLCanvas hätte, weiß ich nicht.

Ich hab das zwischendurch mal gestestet und als Ergebnis funktionierte konnte man eben die Swing Elemente nicht mehr bedienen. Dafür hatte ich den Eindruck, das die Performance und das Rendering besser sind.


Ob der letzte Link die Probleme beseitigt, müsste man man austesten, insbesondere eben mit dem Verarbeiten der Mouseevents. Darauf habe ich jetzt beim Lesen keine Hinweise entdecken könnne.

[Marco13]

Der verlinkte Foreneintrag bezieht sich glaube ich auf etwas anderes: Dort geht es um die Migration vom "alten" JOGL (nämlich dem, das ursprünglich und unabhängig von Sun entwicklet wurde) zum "neuen" JOGL (nämlich dem, das mit JSR und Co in "javax.media..." eingeflossen ist). Dort gab es ein paar subtile Änderungen.

Die Änderungen beim Umstieg von JOGL auf JOGL 2.0 wären nicht so subtil: Es fängt damit an, dass bei JOGL 2.0 (analog zum darunter liegenden OpenGL) keine Dinge wie "glBegin/glEnd" mehr unterstützt werden. Diese werden jetzt durch Vertex Arrays, VBO & Co ersetzt.... Das hätte z.B. schonmal einen gewissen "impact" auf die Sinnhaftigkeit des aktuellen "Geoemetry"-Interfaces... Für JOGL 2.0 sollte es vermutlich eher ein Interface geben, von dem man sich (read-only) ByteBuffers abholen kann, die die Geometrie enthalten. Selbstverständlich sollte es dann "Wrapper" geben, die das alte Geometry-Interface auf das neue abbilden...
Das ist also nicht durch ein update der JAR-Datei erledigt

[Markus]

Oh, da die Begriffe (JSR und JOGL 2.0) oft sehr "nah beieinander" verwendet werden, hatte ich das auch einfach mal gleichgesetzt, sorry.

Also ist eine weitere zentrale Entscheidung, ob man als ersten Schritt auf JOGL 2 migieren will und die weitere Entwicklung dann auf der Basis fortführen möchte, oder?

Ich würde den Schritt deshalb bevorzugen, da man sich so dem "aktuellen" technologischen Stand annähern würde

[Marco13]

Wie gesagt: Der aktuelle Stand von JOGL 2.0 ist wohl noch nicht "final" - man könnte schonmal sondieren, was bei einer Migration alles anfallen würde. Die konkreten Änderungen würden sich, wie angedeutet, wohl in erster Linie in einem neuen Geometry-Interface und der Zeichenmethode von SwoglComponent niederschlagen....