Die GLSurfaceView.Renderer-Schnittstelle des Android-SDK gibt mir eine GL-Schnittstelle als Parameter, die den Typ GL10 hat. Diese Schnittstelle wird von einer privaten internen jni-Wrapper-Klasse implementiert. Aber es gibt auch die Klasse GLES10, in der alle GL-Methoden als statische Methoden zur Verfügung stehen. Gibt es einen wichtigen Unterschied zwischen ihnen? Was passiert, wenn ich den gl-Parameter von onDrawFrame ignoriere und stattdessen die statischen Methoden von GLES10 überall verwende?
Hier ist ein Beispiel. Anstatt dies zu tun:
%Vor%Ich könnte das tun:
%Vor%Der Vorteil ist, dass ich den GL-Kontext nicht an alle aufgerufenen Methoden übergeben muss. Aber selbst wenn es funktioniert (Und es funktioniert, ich habe es ausprobiert) Ich frage mich, ob es irgendwelche Nachteile und Gründe gibt, es NICHT so zu machen.
Ich habe im Quellcode herumgestochert und versucht, genau diese Frage zu beantworten. Soweit ich das beurteilen kann, gehen beide Möglichkeiten, die OpenGL-Implementierung aufzurufen, an denselben nativen Funktionsaufruf. Mein Verständnis ist jedoch, dass der Java-seitige Zugriff durch statische Methoden schneller ist als durch den virtuellen Methodenversand (siehe Ссылка ).
Der Kompromiss besteht darin, dass Sie beim Zugriff auf Aufrufe, die nur in späteren Versionen von OpenGL verfügbar sind, eine gewisse Menge an Typprüfungen opfern. Wenn Sie über das Objekt auf den Aufruf zugreifen, müssen Sie zuerst eine Umwandlung durchführen. Diese Umwandlung schlägt fehl, wenn die verwendete GL-Version die Schnittstelle nicht unterstützt. Wenn ich auf den Aufruf über die statische Methode zugreife, denke ich, dass der OpenGL-Fehlerstatus gesetzt wird. Das kann schwieriger zu erkennen sein, wenn Sie nicht den Debugging-Modus auf der GLSurfaceView gesetzt haben.
Im Moment greife ich über die statischen Methoden auf alles zu und lasse den Debug-Modus im GLSurfaceView so lange eingeschaltet, bis der Code stabil ist. An diesem Punkt werde ich ihn ausschalten.