Android, OpenGL und Erweiterung von GLSurfaceView?

Ich habe eine sehr minimale Erweiterung für mein GLSurfaceView, und der größte Teil der Weisheit gehört zu meiner Implementierung von GLSurfaceView.Renderer. Ich hatte die folgenden drei Gründe, einen Wrapper für GLSurfaceView zu verwenden:

1. Die Basis GLSurfaceView bietet keine Möglichkeit, die Renderer -Instanz zurückzugewinnen. Ich habe mehrere Oberflächen und wenn ich ein UI-Ereignis für eine davon erhalte, möchte ich den Befehl an den entsprechenden Renderer übergeben. Also überschreibe ich setRenderer und behalte die Referenz in meiner erweiterten Klasse.

2. GLSurfaceView.Renderer erhält keine Benachrichtigungen für onDetachedFromWindow() oder surfaceDestroyed(). Dies verursachte einige Probleme bei meiner Implementierung. Meine Erweiterung von GLSurfaceView überschreibt diese Methoden und lässt den mRenderer wissen. Dies ist möglich aufgrund von § 1 .

3. Einige Methoden werden nur umbrochen, um try { super. was auch immer ; } catch() { log( hinzuzufügen Was auch immer ) }. Zum Beispiel wird queueEvent() ausgelöst, wenn der Renderer nicht festgelegt ist. Für mich ist dies jedoch in Ordnung Ignorieren Sie solche Zeitleisteninkonsistenzen einfach.

Kommentare

• I ' Wir haben auch damit begonnen, obwohl die Frage eher darauf abzielt, warum Sie die eigentliche Logik möglicherweise in eine erweiterte GLSurfaceView anstatt in GLSurfaceView.Renderer einfügen . Bei Punkt 1 behalte ich den Renderer als Variable in meiner Aktivität. Theoretisch kann ich es von überall her erhalten, indem ich den Kontext umsetze: ((MyActivity)view.getContext()).getRenderer(). Vielleicht etwas gefährlicher, da das Kontextobjekt nicht unbedingt MyActivity
• sein muss. ' ist in Ordnung, wenn Sie haben ein Renderer. Aber wie ich bereits sagte, haben wir viele Rendrers, die mit verschiedenen SurfaceViews verbunden werden – ein Durcheinander!

Mindestens ein guter Grund, GLSurfaceView zu erweitern, besteht darin, es wie jedes andere Widget direkt aus einer Layout-XML-Datei instanziieren zu können:

 <RelativeLayout ... > <com.example.MyGlSurfaceView android:id="@+id/my_view" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_centerInParent="true" /> </RelativeLayout> 

Kommentare

• Sie können dies trotzdem mit <android.opengl.GLSurfaceView android:id="@+id/graphics_glsurfaceview1" android:layout_width="fill_parent" android:layout_height="fill_parent" />
• tun. Der Unterschied besteht darin, dass in meinem Beispiel das Android-Framework alles aufbläst und einrichtet, ohne dass zusätzliche Codezeilen erforderlich sind. Ihre Methode ist mehr Code, aber flexibel, um die Implementierung zu ersetzen. Davon abgesehen scheinen beide Möglichkeiten ähnlich zu sein.

Nun … GLSurfaceView ist so wie ich Sicher haben Sie bemerkt, nur ein Wrapper für das Gemeinwohl. Er enthält alle Funktionen, die zum Rendern mit opengl erforderlich sind, und bietet die Möglichkeit, ihn gut in die Android View-Hierarchie zu integrieren.

Sie haben ihn nicht bereitgestellt Ihre Alternative ist also nicht zu vergleichen, aber ich hoffe, Sie haben einen anderen Thread zum Rendern erstellt, wie dies bei GLSurfaceView der Fall ist, oder Ihre Benutzereingaben können verzögert sein.

Also noch einmal: GLSurfaceView bietet einen neuen Thread zum Rendern, sodass Sie sich keine Gedanken über Verzögerungen bei Benutzereingaben machen müssen

Kommentare

• Ja, aber GLSurfaceView macht das (startet einen Rendering-Thread), auch wenn Sie ' erweitern es nicht. Ich verwende GLSurfaceView, aber ' erweitere es nicht. Ich ' frage, welche Vorteile es hat, es zu erweitern und die verschiedenen Methoden darin zu überschreiben, anstatt nur alles in der Renderer
• welp, ich habe es versucht 🙂 Ich könnte es später untersuchen, jetzt bin ich auch interessiert!