Best practice for overlaying xml layouts on a GLSurfaceView?

Question

I'm following the examples in a recent book (Learn OpenGL ES For Mobile Game and Graphics Development) and the suggestion made there is to programmatically add a new layout (let's call it settingsLayout) in the main activity and then:

 LayoutInflater settingsInflater = (LayoutInflater) getSystemService(Context.LAYOUT_INFLATER_SERVICE);
 View settingsLayoutView = settingsInflater.inflate(R.layout.mySettingsLayout,settingsLayout,false);
 settingsLayout.addView(settingsLayoutView);
 addContentView(settingsLayout,settingsLayoutParams);

This works fine, but I've added it to the callback for one of my action bar menu items, and I'd like to be able to remove this view when the back button is used. So far, that is causing me a lot of headache.

Meanwhile, it seems that the most natural way to implement dynamic views (addable to backstack, etc) is through Fragments. However, fragments need to belong to a layout, and currently my code assigns the GLSurfaceView directly as the content view for my main activity, without using a layout at all. Since GLSurfaceView is a subclass of View (and not View Group), I cannot use it to spawn children such as fragments.

The author of the book claims that this approach is "sleek", but doesn't give any other reason for assigning the GLSurfaceView directly as the content view. Is there a performance issue to be aware of? Or is it just as "sleek" to make a "master" layout to which both my GLSurfaceView and subsequently spawned views belong?

Is there some other even more natural way to get buttons, text boxes, etc. to dynamically appear and disappear on top of my GLSurfaceView?

Answer 1

I'm not sure what your specific performance concern is -- rendering the View objects, or rendering GL? Nothing you do is going to affect the performance of the GL rendering (except perhaps changing the size of the window).

SurfaceView and GLSurfaceView provide a transparent "place holder" in the View hierarchy that other elements use when computing the layout, but the actual pixels are drawn on a separate layer. This is why the SurfaceView is either behind all View elements or in front of them all -- the layer is passed to the system compositor (SurfaceFlinger), which takes care of generating the final display image.