Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question is part-technical, part-meta, part-subjective and very specific:

I'm an indie game dev working on android, and for the past 6 months I've struggled and finally succeeded in making my own 3D game app for android. So I thought I'd hop on SO and help out others struggling with android and openGL-ES

However, the vast majority of questions relate to extending GLSurfaceView. I made my whole app without extending GLSurfaceView (and it runs fine). I can't see any reason at all to extend GLSurfaceView for the majority of questions I come across.

Worse, the android documentation implies that you ought to, but gives no detailed explaination of why or what the pros/cons are vs not extending and doing everything through implementing your own GLSurfaceView.Renderer as I did

Still, the sheer volume of questions where the problem is purely to do with extending GLSurfaceView is making me wonder whether actually there is some really good reason for doing it that way vs the way I've been doing it (and suggesting in my answers to others to do).

So, is there something I'm missing? Should I stop answering questions in the meantime?

Android openGL documentation

share|improve this question
    
nice question i am keen about answer.. –  TofeeqAhmad Dec 22 '11 at 11:20
    
One reason as to why extend GLSurfaceView can be found here: gamedev.stackexchange.com/questions/12629/… Without realising it, I actually already sidestepped the issues talked about in this question in my own app by reloading textures etc onResume() –  Spoon Thumb Dec 23 '11 at 23:38
add comment

3 Answers

I have a very minimal extension for my GLSurfaceView, and most of the wisdom belongs to my implementation of GLSurfaceView.Renderer. I had the following three reasons to use a wrapper for GLSurfaceView:

  1. The base GLSurfaceView provides no way to get the Renderer instance back. I have multiple surfaces, and when I receive a UI event for one of them, I want to pass the command to the corresponding renderer. So, I override setRenderer and keep the reference in my extended class.

  2. GLSurfaceView.Renderer does not receive notifications for onDetachedFromWindow() or surfaceDestroyed(). This caused some problems to my implementation. My extension of GLSurfaceView overrides these methods and lets the mRenderer know. It's possible because of §1.

  3. Some methods are only wrapped to add try { super.whatever; } catch() { log(whatever) }. For example, queueEvent() will throw if Renderer is not set; but for me, it's OK to simply ignore such timeline inconsistencies.

share|improve this answer
    
I've started doing this as well, though the question is more aimed at why you might put the actual logic in an extended GLSurfaceView rather than GLSurfaceView.Renderer. Though on point 1, I keep the renderer as a variable in my activity. In theory I can get it from anywhere by casting the context: ((MyActivity)view.getContext()).getRenderer(). Perhaps a little more dangerous as the context object may not necessarily be MyActivity –  Spoon Thumb Oct 18 '12 at 18:29
    
It's fine if you have one renderer. But as I said before, we have many rendrers, and they get connected to different SurfaceViews - a mess! –  Alex Cohn Oct 18 '12 at 18:49
add comment

At least one good reason to extend GLSurfaceView is to be able to instantiate it directly from a layout xml file, just as any other 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>
share|improve this answer
1  
You can do that anyway using <android.opengl.GLSurfaceView android:id="@+id/graphics_glsurfaceview1" android:layout_width="fill_parent" android:layout_height="fill_parent" /> –  Spoon Thumb Aug 12 '12 at 23:44
    
Good point. The difference is that in my example the Android framework inflates and setup everything without needing extra lines of code. Your method is more code, but flexible to replace implementation. Other than that, both ways seem similar. –  uval Aug 13 '12 at 7:02
add comment

Well...GLSurfaceView is, as I am sure you've noticed, just a wrapper for common good. It encapsulates all the functionality one would need to render with opengl, having the option to incorporate it nicely with the android View hierarchy.

You did not provide your alternative so it is impossible to compare, but I hope you spawned another thread for rendering as GLSurfaceView does, or your user input might lag.

So again: GLSurfaceView provides a new thread for rendering, so you dont have to worry about user input lag

share|improve this answer
1  
Yes, but GLSurfaceView does that (starts a rendering thread) even if you don't extend it. I use GLSurfaceView, but I don't extend it. I'm asking what benefits are there from extending it and overrriding the different methods therein as opposed to just having everything in the Renderer –  Spoon Thumb Jan 3 '12 at 12:05
    
welp, I tried :) I might look into it later, now I am also interested! –  Greg Jan 4 '12 at 16:15
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.