Game Development Reference
In-Depth Information
Nexus One:
12-10 03:28:05.923: DEBUG/FPSCounter(930): fps: 43
12-10 03:28:06.933: DEBUG/FPSCounter(930): fps: 43
12-10 03:28:07.943: DEBUG/FPSCounter(930): fps: 44
12-10 03:28:08.963: DEBUG/FPSCounter(930): fps: 44
12-10 03:28:09.973: DEBUG/FPSCounter(930): fps: 44
12-10 03:28:11.003: DEBUG/FPSCounter(930): fps: 43
12-10 03:28:12.013: DEBUG/FPSCounter(930): fps: 44
Upon first inspection, we can see the following:
The Hero is twice as slow as the Droid and the Nexus One.
ï?®
The Nexus One is slightly faster than the Droid.
ï?®
We generate garbage on the Hero in our process (17883).
ï?®
Now, the last item on that list is somewhat puzzling. We run the same code on all three devices.
Upon further inspection, we do not allocate any temporary objects in either the
present()
method or the
update()
method. So what's happening on the Hero?
The Curious Case of the Hero on Android 1.5
It turns out that there is a bug in Android 1.5. Well, it's not
really
a bug, it's just some extremely
sloppy programming. Remember that we use direct NIO buffers for our vertices and indices?
These are actually memory blocks in native heap memory. Each time we call
glVertexPointer()
,
glColorPointer()
, or any other of the
glXXXPointer()
methods, OpenGL ES will try to fetch
the native heap memory address of that buffer to look up the vertices to transfer the data to
video RAM. The problem on Android 1.5 is that each time we request the memory address
from a direct NIO buffer, it will generate a temporary object called
PlatformAddress
. Since we
have a lot of calls to the
glXXXPointer()
and
glDrawElements()
methods (remember, the latter
fetches the address from a direct
ShortBuffer
), Android allocates a metric ton of temporary
PlatformAddress
instances, and there's nothing we can do about it. (Actually, a workaround is
available, but for now we won't discuss it.) Let's just accept the fact that using NIO buffers on
Android 1.5 is horribly broken and move on.
What's Making My OpenGL ES Rendering So Slow?
That the Hero is slower than the second-generation devices is no big surprise. However, the
PowerVR chip in the Droid is slightly faster than the Adreno chip in the Nexus One, so the
preceding results are a little bit strange at first sight. Upon further inspection, we can probably
attribute the difference not to the GPU power but to the fact that we call many OpenGL ES
methods each frame, which are costly Java Native Interface methods. This means that they
actually call into C code, which costs more than calling a Java method on Dalvik. The Nexus
One has a JIT compiler and can optimize a little bit there. So let's just assume that the difference
stems from the JIT compiler (which is probably not entirely correct).
