FPS measurement woes.

Tutorials concerning the OpenGL® ES cross-platform API for full-function 2D and 3D graphics on the Google-Android platform.

FPS measurement woes.

Postby ShadowKntSDS » Thu May 13, 2010 7:10 pm

DISCLAIMER: I know the SpriteMethodTest code is pretty old and far from optimal.

I coded a very simple tetris clone to get started, and wanted to see how bad the frames per second would be for my implementation. After setting up some code to dump a FPS measurement to logcat over a USB cable, I noticed that the FPS i was getting was way lower than what SpriteMethodTest was getting for roughly the same complexity. I was getting roughly ~18-22 FPS, while the SpriteMethodTest was reporting ~40-50. My app was rendering ~100 32x32 sprites using glDrawTexfOES, so i was expecting roughly similar result. When my app is paused, the physics update loop is short circuited, so I know I am not spending eons doing other calcs. Pausing doesn't seem to alter the FPS by any noticeable margin. I also set all of my textures to the same one, to make sure the texture binding wasn't slowing me down, with no impact on FPS. I also forced the device to NOT run in compatibility mode, as it was doing a zoom-to-fit type of operation before. No change in FPS.

This is on a Droid Incredible btw. I know this is fill rate limited, but this seems pretty silly.

After some investigating, I realized that the numbers produced by SpriteMethodTest were purely based on the time spent during onDraw + the page flip, and not a true measure of FPS. So I added the same code I was using to measure FPS in my app to SpriteMethodTest. It got roughly the same results as my app. I add more sprites, and SpritMethodTest reports lower fps, but the logcat listed fps doesn't change much if at all.

The funny thing is that the screen drawing looks faster than 20 fps, so now I am doubting the code i used (or my eyes). I essentially stole the code used in SpriteText, and converted it to use Log() instead of writing sprites on the screen. I execute this at the end of each drawFrame().

Syntax: [ Download ] [ Hide ]
Using java Syntax Highlighting
  1.  
  2.     private final static float SAMPLE_FACTOR = 1.0f / SAMPLE_PERIOD_FRAMES;
  3.  
  4.  
  5.  
  6.  
  7.  
  8.     private void drawMsPF(GL10 gl, float rightMargin) {
  9.  
  10.         long time = SystemClock.uptimeMillis();
  11.  
  12.         if (mStartTime == 0) {
  13.  
  14.             mStartTime = time;
  15.  
  16.         }
  17.  
  18.         if (mFrames++ == SAMPLE_PERIOD_FRAMES) {
  19.  
  20.             mFrames = 0;
  21.  
  22.             long delta = time - mStartTime;
  23.  
  24.             mStartTime = time;
  25.  
  26.             mMsPerFrame =  (delta * SAMPLE_FACTOR);
  27.  
  28.             if (mMsPerFrame > 0) {
  29.  
  30.                 Log.v(TAG, "fps = " + mMsPerFrame);
  31.  
  32.             }
  33.  
  34.         }
  35.  
  36.  
  37.  
  38.     }
Parsed in 0.032 seconds, using GeSHi 1.0.8.4



I don't see anything obviously wrong with this code. I played around with SAMPLE_PERIOD_FRAMES a good bit, but the results seemed fairly stable.

1. How are other people measuring FPS?
2. Is there anything wrong the code above for measuring the true number of frames per second?
3. Any ideas as to why SpriteMethodTest reports numbers that are so vastly different than the logcat data I was getting? I expected some difference, but not that huge.
ShadowKntSDS
Junior Developer
Junior Developer
 
Posts: 15
Joined: Wed Apr 28, 2010 10:29 pm

Top

Postby astrath » Sun May 16, 2010 8:25 pm

That's quite interesting. I haven't checked what you said about SpriteMethodTest, but this would mean that any fps it shows are bogus and unusable. Also this would mean that my own code isn't quite so bad compared to SpriteMethodTest;)

To me there is nothing wrong with your fps code. It's not like there are a lot of possibilities to calculate the framerate (1000 / now-lastFrameTime, what else?).

Outputting the fps over the USB cable via Log didn't change them from writing them on the screen for me.
astrath
Junior Developer
Junior Developer
 
Posts: 12
Joined: Thu Apr 08, 2010 1:03 pm

Postby ShadowKntSDS » Sun May 16, 2010 8:58 pm

I've done a little bit more research and found that in order to really squeeze out max FPS, you'd need to have a separate thread to get around the GPU blocking the cpu during the page flip. Sadly, this doesn't explain the difference I'm seeing as SpriteMethodTest as the "fps" guestimate includes the time taken for the page flip.
ShadowKntSDS
Junior Developer
Junior Developer
 
Posts: 15
Joined: Wed Apr 28, 2010 10:29 pm

Re: FPS measurement woes.

Postby ShadowKntSDS » Tue May 18, 2010 6:13 am

Looks like the code I was using was dumping ms per frame and not frame per second. Silly me for not noticing.

I started getting suspicious when my "fps" went down when I removed stuff from the scene. I decided to learn how to use Traceview, and saw that a blank screen was rendering in 10ms, and i should be getting ~100fps, and not ~13. At least I learned how to use traceview.
ShadowKntSDS
Junior Developer
Junior Developer
 
Posts: 15
Joined: Wed Apr 28, 2010 10:29 pm

Top

Return to Android 2D/3D Graphics - OpenGL Tutorials

Who is online

Users browsing this forum: No registered users and 3 guests