Android, OpenGL i rozszerzenie GLSurfaceView?

To pytanie jest częściowo techniczne, częściowo meta, częściowo subiektywne i bardzo szczegółowe:

Jestem niezależnym twórcą gier pracującym na Androidzie i przez ostatnie 6 miesięcy miałem problemy i wreszcie udało mi się stworzyć własną aplikację do gier 3D na Androida. Pomyślałem więc, że wskoczę na SO i pomogę innym zmagającym się z Androidem i openGL-ES

Jednak zdecydowana większość pytań dotyczy rozszerzenia GLSurfaceView. Zrobiłem całą aplikację bez rozszerzania GLSurfaceView(i działa dobrze). Nie widzę żadnego powodu, aby rozciągać się GLSurfaceViewna większość pytań, które napotkałem.

Co gorsza, dokumentacja Androida sugeruje, że powinieneś, ale nie zawiera szczegółowego wyjaśnienia, dlaczego lub czym są zalety / wady, a nie przedłużanie i robienie wszystkiego poprzez wdrożenie własnego, GLSurfaceView.Renderertak jak ja

Mimo to sama liczba pytań, w których problem dotyczy wyłącznie rozszerzenia, GLSurfaceViewsprawia, że ​​zastanawiam się, czy rzeczywiście istnieje jakiś naprawdę dobry powód, aby zrobić to w ten sposób w porównaniu do sposobu, w jaki to robiłem (i sugerując w odpowiedziach dla innych do zrobienia).

Czy jest coś, za czym tęsknię? Czy w międzyczasie powinienem przestać odpowiadać na pytania?

Dokumentacja openGL Androida

Mam bardzo minimalne rozszerzenie dla siebie GLSurfaceViewi większość mądrości należy do mojej implementacji GLSurfaceView.Renderer. Miałem następujące trzy powody, dla których warto użyć opakowania GLSurfaceView:

1. Baza GLSurfaceViewnie umożliwia odzyskania Rendererinstancji. Mam wiele powierzchni, a gdy otrzymuję zdarzenie interfejsu użytkownika dla jednej z nich, chcę przekazać polecenie do odpowiedniego mechanizmu renderującego. Zastępuję setRendereri zachowuję referencję w mojej rozszerzonej klasie.

2. GLSurfaceView.Renderernie otrzymuje powiadomień dotyczących onDetachedFromWindow()lub surfaceDestroyed(). Spowodowało to pewne problemy z moją implementacją. Moje rozszerzenie GLSurfaceViewzastępuje te metody i informuje mRenderer . Jest to możliwe dzięki §1 .

3. Niektóre metody są owinięte tylko dodać try { super.cokolwiek ; } catch() { log(cokolwiek) } . Na przykład queueEvent()wyrzuci, jeśli moduł renderujący nie jest ustawiony; ale dla mnie OK jest po prostu ignorować takie niespójności na osi czasu.

Co najmniej jednym dobrym powodem do rozszerzenia GLSurfaceView jest możliwość utworzenia go bezpośrednio z pliku XML układu, tak jak każdy inny widget:

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

Cóż ... GLSurfaceView jest, jak jestem pewien, zauważyłeś, tylko opakowaniem dla wspólnego dobra. Zawiera wszystkie funkcje, które należałoby renderować za pomocą opengl, z opcją ładnego włączenia go w hierarchię widoku Android.

Nie podałeś swojej alternatywy, więc nie można jej porównać, ale mam nadzieję, że stworzyłeś inny wątek do renderowania, tak jak robi to GLSurfaceView, lub twoje dane wejściowe mogą być opóźnione.

Więc jeszcze raz: GLSurfaceView zapewnia nowy wątek do renderowania, więc nie musisz się martwić opóźnieniem wprowadzania danych przez użytkownika