Android, OpenGL e estensione GLSurfaceView?

Question

Android, OpenGL e estensione GLSurfaceView?

#1 da (2 voti)
#2 da (0 voti)
#3 da (-1 voti)

12

Questa domanda è in parte tecnica, in parte meta, in parte soggettiva e molto specifica:

Sono uno sviluppatore di giochi indie che lavora su Android e negli ultimi 6 mesi ho faticato e finalmente sono riuscito a creare la mia app di gioco 3D per Android. Quindi ho pensato di salire su SO e aiutare gli altri a lottare con Android e openGL-ES

Tuttavia, la stragrande maggioranza delle domande riguarda l'estensione di GLSurfaceView . Ho creato la mia intera app senza estendere GLSurfaceView (e funziona bene). Non vedo alcun motivo per estendere GLSurfaceView per la maggior parte delle domande che ho incontrato.

Peggio, la documentazione di Android implica che è necessario, ma non fornisce spiegazioni dettagliate sul motivo o su cosa i pro / contro sono contro non estendere e fare tutto attraverso l'implementazione del proprio GLSurfaceView.Renderer come ho fatto io

Tuttavia, il semplice volume di domande in cui il problema ha a che fare con l'estensione di GLSurfaceView mi fa domandare se effettivamente ci sia davvero una buona ragione per farlo in questo modo rispetto al modo in cui lo sto facendo (e suggerendo nelle mie risposte agli altri di fare).

Quindi, c'è qualcosa che mi manca? Dovrei smettere di rispondere alle domande nel frattempo?

documentazione Android openGL

opengl android

posta Spoon Thumb 17.12.2011 - 00:36

fonte

3 risposte

Leggi altre domande sui tag opengl android

Approccio euristico per implementazione flessibile DIFF Modelli per applicazioni web ajax-heavy

score 2 · Answer 1

Ho un'estensione molto minima per il mio GLSurfaceView , e la maggior parte della saggezza appartiene alla mia implementazione di GLSurfaceView.Renderer . Ho avuto i seguenti tre motivi per utilizzare un wrapper per GLSurfaceView :

La base GLSurfaceView non consente di recuperare l'istanza Renderer . Ho più superfici e quando ricevo un evento UI per una di esse, voglio passare il comando al renderer corrispondente. Quindi, sovrascrivo setRenderer e mantieni il riferimento nella mia classe estesa.
GLSurfaceView.Renderer non riceve notifiche per onDetachedFromWindow() o surfaceDestroyed() . Ciò ha causato alcuni problemi alla mia implementazione. La mia estensione di GLSurfaceView ha la precedenza su questi metodi e consente a mRenderer di sapere. È possibile a causa di §1 .
Alcuni metodi sono solo avvolti per aggiungere try { super. qualunque ; } catch() { log( qualunque ) } . Ad esempio, queueEvent() verrà lanciata se Renderer non è impostato; ma per me, è giusto ignorare tali incoerenze della timeline.

score 0 · Answer 2

Almeno un buon motivo per estendere GLSurfaceView è poter essere istanziato direttamente da un file xml di layout, proprio come qualsiasi altro 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>

score -1 · Answer 3

Bene ... GLSurfaceView è, come sono sicuro tu abbia notato, solo un involucro per il bene comune. Incapsula tutte le funzionalità necessarie per il rendering con opengl, avendo la possibilità di incorporarlo correttamente con la gerarchia di Android View.

Non hai fornito la tua alternativa quindi è impossibile confrontare, ma spero che tu abbia generato un altro thread per il rendering come fa GLSurfaceView, altrimenti il tuo input dell'utente potrebbe essere in ritardo.

Ancora una volta: GLSurfaceView fornisce un nuovo thread per il rendering, quindi non devi preoccuparti del ritardo di input dell'utente