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

Spoon Thumb
  • 229
  • 2
  • 4
  • nice question i am keen about answer.. – Tofeeq Dec 22 '11 at 11:20
  • One reason as to why extend GLSurfaceView can be found here: http://gamedev.stackexchange.com/questions/12629/workaround-to-losing-the-opengl-context-when-android-pauses 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

3 Answers3

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.

Alex Cohn
  • 129
  • 5
  • 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
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>
Amir Uval
  • 101
  • 2
  • 1
    You can do that anyway using `` – 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. – Amir Uval Aug 13 '12 at 07: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

gcasar
  • 101
  • 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` – Spoon Thumb Jan 03 '12 at 12:05
  • welp, I tried :) I might look into it later, now I am also interested! – gcasar Jan 04 '12 at 16:15