¿Android, OpenGL y GLSurfaceView extendido?

12

Esta pregunta es en parte técnica, en parte meta, en parte subjetiva y muy específica:

Soy un desarrollador de juegos independiente que trabaja en Android, y durante los últimos 6 meses he tenido problemas y finalmente he logrado crear mi propia aplicación de juegos 3D para Android. Así que pensé en subirme a SO y ayudar a otros que luchan con Android y OpenGL-ES

Sin embargo, la gran mayoría de las preguntas se relacionan con la extensión GLSurfaceView. Hice toda mi aplicación sin extenderla GLSurfaceView(y funciona bien). No veo ninguna razón para extender GLSurfaceViewla mayoría de las preguntas que encuentro.

Peor aún, la documentación de Android implica que deberías hacerlo, pero no da una explicación detallada de por qué o cuáles son los pros / contras frente a no extender y hacer todo a través de la implementación de la tuya GLSurfaceView.Renderercomo lo hice yo.

Aún así, el gran volumen de preguntas en las que el problema tiene que ver únicamente con la extensión GLSurfaceViewme hace preguntarme si realmente hay alguna razón realmente buena para hacerlo de esa manera frente a la forma en que lo he estado haciendo (y sugiriendo en mis respuestas a otros que hacer).

Entonces, ¿hay algo que me falta? ¿Debo dejar de responder preguntas mientras tanto?

Documentación de Android OpenGL

android opengl

— Cuchara Pulgar
fuente

buena pregunta que estoy interesado en la respuesta ..

— Tofeeq

Una razón de por qué extender GLSurfaceView se puede encontrar aquí: gamedev.stackexchange.com/questions/12629/... Sin darme cuenta, en realidad ya esquivé los problemas mencionados en esta pregunta en mi propia aplicación recargando texturas, etc.onResume()

— Spoon Thumb

2

Tengo una extensión mínima para mi GLSurfaceView, y la mayor parte de la sabiduría pertenece a mi implementación de GLSurfaceView.Renderer. Tenía las siguientes tres razones para usar un contenedor para GLSurfaceView:

La base GLSurfaceViewno proporciona forma de recuperar la Rendererinstancia. Tengo varias superficies, y cuando recibo un evento de IU para una de ellas, quiero pasar el comando al renderizador correspondiente. Entonces, anulo setRenderery mantengo la referencia en mi clase extendida.
GLSurfaceView.Rendererno recibe notificaciones de onDetachedFromWindow()o surfaceDestroyed(). Esto causó algunos problemas a mi implementación. Mi extensión de GLSurfaceViewanula estos métodos y se lo hace saber al mRenderer . Es posible debido a §1 .
Algunos métodos solo se envuelven para agregar try { super.lo que ; } catch() { log(sea) } . Por ejemplo, queueEvent()lanzará si Renderer no está configurado; pero para mí, está bien simplemente ignorar tales inconsistencias en la línea de tiempo.

— Alex Cohn
fuente

También comencé a hacer esto, aunque la pregunta está más orientada a por qué podría poner la lógica real en una extensión en GLSurfaceViewlugar de hacerlo GLSurfaceView.Renderer. Aunque en el punto 1, mantengo el renderizador como una variable en mi actividad. En teoría lo puedo conseguir desde cualquier lugar colando el contexto: ((MyActivity)view.getContext()).getRenderer(). Tal vez un poco más peligroso ya que el objeto de contexto puede no ser necesariamente necesarioMyActivity

— Spoon Thumb

Está bien si tienes un renderizador. Pero como dije antes, tenemos muchos reproductores, y se conectan a diferentes SurfaceViews, ¡un desastre!

— Alex Cohn

0

Al menos una buena razón para extender GLSurfaceView es poder instanciarlo directamente desde un archivo xml de diseño, como cualquier otro 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>

— Amir Uval
fuente

1

Puede hacerlo de todos modos usando

<android.opengl.GLSurfaceView  		android:id="@+id/graphics_glsurfaceview1"  		android:layout_width="fill_parent"  		android:layout_height="fill_parent" 	/>

— Spoon Thumb

Buen punto. La diferencia es que, en mi ejemplo, el marco de Android se infla y configura todo sin necesidad de líneas de código adicionales. Su método es más código, pero flexible para reemplazar la implementación. Aparte de eso, ambas formas parecen similares.

— Amir Uval

-1

Bueno ... GLSurfaceView es, como estoy seguro de que has notado, solo un contenedor para el bien común. Encapsula toda la funcionalidad que uno necesitaría para renderizar con opengl, teniendo la opción de incorporarlo bien con la jerarquía de Vista de Android.

No proporcionó su alternativa, por lo que es imposible comparar, pero espero que haya generado otro hilo para renderizar como lo hace GLSurfaceView, o su entrada de usuario podría retrasarse.

Así que de nuevo: GLSurfaceView proporciona un nuevo hilo para renderizar, por lo que no tiene que preocuparse por el retraso de entrada del usuario

— Greg
fuente

2

Sí, pero lo GLSurfaceViewhace (comienza un hilo de renderizado) incluso si no lo extiende. Yo uso GLSurfaceView, pero no lo extiendo. Estoy preguntando qué beneficios hay al extenderlo y anular los diferentes métodos allí en lugar de tener todo en elRenderer

— Spoon Thumb

welp, lo intenté :) Podría investigarlo más tarde, ¡ahora también estoy interesado!

— Greg