*Notes:
Debug/Run appear to be running the same speed (assume maybe on Run its not really a release build?)
FPS = 10
Other Benchmarks appear to run 25FPS with 60K triangles on my phone
Not threaded, but I have seen no examples of how to setup the GLSurfaceView on another thread...

I messed with android about a year ago, and the emulator on pc was extremely slow. Now that I have a Droid phone, I see way better framerates than the emulator but they still suck.

I create a GL 1.0 context (instead of 2.0 because of the tutorials I found and no point to move on if my performance is garbage).


At startup I load a single triangle, and duplicate the indices 0,1,2 over and over again to like 800 times. So I'm overdrawing the same triangle 800 times. So if I translate -100, the triangle draws very small, so that I can determine my issue to be vertex rather than pixel shader/fill-rate issue.


Every Frame here is my code:
<code>
public void onDrawFrame(GL10 gl)
{
long currTime = System.currentTimeMillis();
long elapsed = currTime - mLastTime;
mLastTime = currTime;
if(elapsed > 1)
{
mFPS = (int) (1000.0/elapsed);
}
else
{
mFPS = 1000;

}

GL.gl.glClearColor(1, 1, 0, 0);
GL.gl.glClear(GL10.GL_COLOR_BUFFER_BIT | GL10.GL_DEPTH_BUFFER_BIT);

GL.gl.glLoadIdentity();
GL.gl.glRotatef(rotation++, 0,0,1);
GL.gl.glTranslatef(0, 0, -100);

m.draw();

}
</code>





......Then my draw code. Is this not a VBO? I looked at some 1.0 + 2.0 and never saw a call to glBindBuffer like I do on PC. I just looked at GLES 2.0 spec and glBindBuffer is there, so is this sending the data over or is this not a true vbo?
<code>
public void draw()
{
GL.gl.glDisable(GL10.GL_CULL_FACE);
GL.gl.glCullFace(GL10.GL_BACK);

GL.gl.glEnable(GL10.GL_TEXTURE_2D);
GL.gl.glBindTexture(GL10.GL_TEXTURE_2D, 1);


GL.gl.glEnableClientState(GL10.GL_VERTEX_ARRAY);

GL.gl.glVertexPointer(3, GL10.GL_FLOAT, 0,
vertexBuffer);

GL.gl.glEnableClientState(GL10.GL_TEXTURE_COORD_ARRAY);
GL.gl.glTexCoordPointer(2, GL10.GL_FLOAT, 0, mTextureBuffer);

GL.gl.glDrawElements(GL10.GL_TRIANGLES, indices.length,
GL10.GL_UNSIGNED_SHORT, indexBuffer);

GL.gl.glDisableClientState(GL10.GL_VERTEX_ARRAY);
}
</code>

you're using a vertex array, not a VBO (You need to use GL:ES 1.1 for VBO if a phone only has 1.0 you need to check if the extension is available) that shouldn't make a big difference unless you have very high vertex counts though (3 vertices and 800 indices shouldn't be a problem to transmit each frame)

Now the big question is: How do you know the fps sucks on an actual phone ?
How do you display the fps ? (You're not showing this at all, if done the wrong way this by itself can slow down your application dramatically).

Also a few minor things:

1) Don't enable/disable clientstate if its not required.
2) How are you creating your buffers ? (This can have a impact on performance)

Yea I know how to optimize GL, and not to enable/disable, right now I'm in that "get running then scrap and refactor". I just looked this up and realized that is actually how a vertex array looks in code. I assumed it was, but never used because of VBO's.

I calculate the FPS with the above code, which sets a static variable. Then I put a breakpoint with an onTouchEvent. So when I tap the screen it breaks there, and I can lookup the static variable in my render class. Without rendering it hits very close to 60, which it says GLES renders no more than 60FPS and caps it.

As for it being slow, I think that it would be pretty slow to send that every frame (I guess). It is 800 triangles (so 2400 indices each frame). From the android site it looks like I can still try using GLES 2 without completely going to the native SDK at this point as I'm doing java and just trying to get benchmarking and pipelines up.

Yea I know how to optimize GL, and not to enable/disable, right now I'm in that "get running then scrap and refactor". I just looked this up and realized that is actually how a vertex array looks in code. I assumed it was, but never used because of VBO's.

I calculate the FPS with the above code, which sets a static variable. Then I put a breakpoint with an onTouchEvent. So when I tap the screen it breaks there, and I can lookup the static variable in my render class. Without rendering it hits very close to 60, which it says GLES renders no more than 60FPS and caps it.

As for it being slow, I think that it would be pretty slow to send that every frame (I guess). It is 800 triangles (so 2400 indices each frame). From the android site it looks like I can still try using GLES 2 without completely going to the native SDK at this point as I'm doing java and just trying to get benchmarking and pipelines up.

So you're running the game with the debugger attached to the phone ? (It might perform better without the debugger), if you're running using the emulator performance will be awful once you start rendering(OpenGL:ES in the emulator is slow, very slow). (My current project hits around 2fps in the emulator and sits steadily at 60 when running on my phone) (What i did to display framerate before i got text rendering sorted was to draw a white thin quad across the top of the screen and then draw a blue quad of the same size but scaled on the x axis by fps/maxrefreshrate)
you can get the max render rate using:
float refreshrate = getWindowManager().getDefaultDisplay().getRefreshRate();
its usually 30 or 60 depending on the phone.

Sending 2400 indices shouldn't be a problem either, its basically nothing.

You didn't answer the question on buffer creation though, are you using native byte order for the buffers ?

I saw some pretty substantial (~10%) gains from using VAO as well, on iOS.

Yea I use native order.

How do I not run with the debugger though? I'm using eclipse, there is Debug or Run. (assume that is like debug/release). So deploying it to the phone with either option appears to be the same speed for the rotating triangle.

Could the speed problem be that I'm not using the NDK with c++ and using the java sdk instead?

Yea I use native order.

How do I not run with the debugger though? I'm using eclipse, there is Debug or Run. (assume that is like debug/release). So deploying it to the phone with either option appears to be the same speed for the rotating triangle.

Could the speed problem be that I'm not using the NDK with c++ and using the java sdk instead?

Java is fast enough on Android (The opengl implementation is native anyway), Right click the project, select android tools, export signed application package, select the keystore (which you create using the keytool that comes with the android sdk) , upload the resulting apk file to your phone and install it and then launch it just like you would any other app, if thats still too slow you could post your full sourcecode here or in a pm and i can take a closer look at it.

It is fixed, no idea what I did. So I did the signing thing and used the cmd line install. It made me uninstall the app on the phone. Then it was slow because my translation was only 10 (so it was a huge fill-rate because of raster size of object). Then I just re-translated to -100 and it was fine. I toggled the .xml android:debuggable=true/false so I don't know if that was what made it go faster, but toggling that currently has no effect.

Bottom line, I'm seeing good render results (for now).