The GLSurfaceView.Renderer interface of the Android SDK gives me a GL interface as parameter which has the type GL10. This interface is implemented by some private internal jni wrapper class. But there is also the class GLES10 where all the GL methods are available as static methods. Is there an important difference between them? So what if I ignor开发者_StackOverflowe the gl parameter of onDrawFrame and instead use the static methods of GLES10 everywhere?
Here is an example. Instead of doing this:
void onDrawFrame(GL10 gl)
{
drawSomething(gl);
}
void drawSomething(GL10 gl)
{
gl.glLoadIdentity();
...
}
I could do this:
void onDrawFrame(GL10 gl)
{
drawSomething();
}
void drawSomething()
{
GLES10.glLoadIdentity();
...
}
The advantage is that I don't have to pass the GL context to all called methods. But even it it works (And it works, I tried it) I wonder if there are any disadvantages and reasons to NOT do it like that.
I've been poking around in the source code trying to answer that very question. As far as I can tell, both ways of invoking the OpenGL implementation go to the same native function call. However, my understanding is that the Java-side access is faster through static methods rather than through virtual method dispatch (see http://developer.android.com/guide/practices/design/performance.html#prefer_static).
The tradeoff is that you sacrifice a certain amount of type-checking when accessing calls that are only available in later versions of OpenGL. When you access the call through the object, you have to do a cast first, and that cast will fail if the version of GL you're using doesn't support the interface. When accessing the call through the static method, I think what will happen is that the OpenGL error state will be set, which can be harder to detect unless you've set the debugging mode on the GLSurfaceView.
For right now I'm accessing everything through the static methods, and I'll leave debug-mode on in the GLSurfaceView until the code is stable, at which point I'll turn it off.
- Kris
精彩评论