Ja, das wird noch kommen. Zur Zeit gibt es wichtigere Sachen die es zu entwickeln/fixen gilt. Ansonsten ist ein ES Binding recht schnell geschrieben, vorausgesetzt man hat die Zeit dazu. JOGL verfolgt hier auch eindeutig ein anderes Ziel. Während JOGL auf den Desktop abzielt, ist LWJGL vor allem klein und ein nahezu reines OGL Binding mit etwaigen Tools. Wie das einfache switchen des Displays von und zu Standalone Desktop, Applet sowie AWT/Swing Canvas.

_________________
(\__/)
(='.'=)
(")_(")

Hallo,

ich glaube, das was über den Performancevergleich zwischen Jogl und z.B. OpenGL mit C gesagt wurde, Quatsch ist.
Selbst wenn Java ca. 2 bis 3 Mal so langsam wie C ist, wirkt sich das so gut wie kaum auf die OpenGL Performance aus, selbst bei Demos, die im 1000er FPS-Bereich liegen wird man keinen Unterschied merken, solange man nicht extrem viel auf der Anwendungsseite berechnet.

Ansonsten find ich den Benchmark von WarrenFaith ganz gut, WebGL unter Firefox scheint bei mir ca. 40 Mal langsamer als im Applet zu sein...

Viele Grüße
dj3hut1

_________________
Wenn Gauß heute lebte, wäre er ein Hacker.
Peter Sarnak, Professor an der Princeton University

Darüber hat doch bisher keiner eine Aussage gebracht. Bisher
Der Gedanke, dass OpenGL bei C/C++ und JOGL die gleiche Leistung bringen sollten ist fast richtig. Durch das ganze wrappen und dem recht langsamen JNI geht schon ein bisschen Leistung pflöten aber wohl nicht die 33-66% wie genannt. Würde man man mir die Pistole auf die Brust setzen und erwarten eine Zahl aus zu sprucken, dann würde ich eher 5-10% sagen.

In einigen Bereichen ist Java schneller als C aber bei gleichen Zeitaufwand kommt mit C++ der schnellere Code rum. Der Compiler und viele Bibliotheken haben hier einfach den Altersunterschied und damit auch optimierung zum Vorteil. Noch dazu treffen unterschiedliche Programmierstiele aufeinander. Die Anzahl an Java Game developer ist im vergleich zu C++ Game Developer quasi nicht existent. Das bedeutet weniger Fachartikel, Tricks/Kniffe, Optimierungen, Code Snippets und so weiter. Ich denke das dort das Problem der Performanceunterschiede von z.B. Quake3(c/c++) und Chrome(q3 engine über Java gewrapped und in Java programmierte Logik) liegt. Was in Java schnell ist muss nicht in C++ schnell sein und umgekehrt und einige dinge können nicht mal portiert werden, ich denke nur an die Macros und Templates von C++ oder den Klassen modifiern von Java. Viele genutzte Bibliotheken sind C und müssen dann gewrapped werden, das kostet dann an jeder Stelle(Sound,Physik,Netzwerk,...) Leistung, welche mit einer reinen Java Variante entfallen würde.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Hallo,

auf 5-10% Verlust kommt man denk ich kaum, es sei denn man hat mehrere (zehn?, hundert?)tausend GL-Funktionsaufrufe pro Frame (dann hat man etweder schlecht programmiert oder schon eine ziemlich komplexe Anwendung). Die grösste Rechenarbeit findet immer noch auf der Grafikkarte statt (sollte jedenfalls), deshalb würden die JNI-Calls in den meisten Fällen so gut wie nicht ins Gewicht fallen.

Viele Grüße
dj3hut1

_________________
Wenn Gauß heute lebte, wäre er ein Hacker.
Peter Sarnak, Professor an der Princeton University

Bekommt man relativ einfach herraus.
Ein 3Eck 1k in Java zeichnen und einmal in c. Das ganze messen und vom Java Ergebnis abziehen, dann hast den overhead und den Wert dann mit der C Zeit dividieren und dann /100 und du hast %.

Es kommt auch drauf an welche API man nutzt, wärend OpenGL1.2-1.5 wesentlich mehr CPU-Zeit verbraten wird, sollte OpenGL2-4.1 und ES2 wesentlich weniger CPU-Zeit verbrauchen. Die letzten beiden sind ja Buffer und Objekt basiert und benötigen wesentlich weniger calls.
Den Umstieg merkt man auch schon unter C selber. Fast alle OpenGL Calls benötigen ja ne Hardware Sync, um die Daten auf die GPU zu bringen und das kostet auch noch mal Zeit. Dann wird die Anzahl aller benötigten Calls massiv gesenkt, da man VBO, Shader und FBO hat, statt glBegin/End, glVertice,glTexture,glColor,glNormal,... . Deswegen hatte man mit OpenGL3 auch vor geschlagen die ID's ein zu äschern und auf VMem Pointer um zu steigen. Dann müsste man auch die ganzen Bind Befehle nicht mehr machen(die nun den größten Anteil haben). NVidia hat ne Extension aber bis dato hat es diese nicht zu einer ARB geschafft.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004