12

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

2
  • nice question i am keen about answer..
    – Tofeeq
    Dec 22, 2011 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() Dec 23, 2011 at 23:38

3 Answers 3

2

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.

2
  • 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 Oct 18, 2012 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, 2012 at 18:49
0

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>
2
  • 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" /> Aug 12, 2012 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.
    – Amir Uval
    Aug 13, 2012 at 7:02
-1

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

2
  • 2
    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 Jan 3, 2012 at 12:05
  • welp, I tried :) I might look into it later, now I am also interested!
    – gcasar
    Jan 4, 2012 at 16:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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