Jun 11 AT 1:01 PM Sean Riley 53 Comments

Evo 4G is getting throttled at 30 fps in 2D and 3D modes

Reports from XDA forums and the Android Developer’s Google Group are indicating that the HTC Evo 4G has its frame rate pegged at 30 frames per second in 2d (Canvas) and 3d (openGL) modes. Where you should be noticing this limitation is in any graphically intensive games or possibly while scrolling or swiping.

How does this compare to other HTC devices you ask? Not well is the answer. The HTC Hero clocks in at an average of 54 fps on the same test. You can give this a shot yourself if you like, the app is “fps2d” which you can download using the QR code, and if you do check it out let us know your results in comments.

One Google staffer was quick to point out that this is not a limitation placed on the Evo by Android.

It is certainly not the goal of the Android team to ship devices locked at 30 FPS. Our target was, is and will be 60 FPS.Romain GuyAndroid Framework Engineer at Google

So the fault can be placed squarely at HTC’s feet, but the good news is no one believes this is an issue with the Evo’s hardware which should mean that a firmware update — or our friends over at XDA — should be able to cook up a fix now that the problem has been identified.

So do you Evo owners out there feel like things are stuttering or poking along a little more than you would have expected from your 1GHz superphone or has real world performance been just fine in your experience?

Via: XDA-Forums

Source: Android Developer's Google Group

Sean has been with Android and Me for over 4 years and covering mobile for the last 5. He occasionally muses about gadgets and tech outside of the Android universe at Techgasms.

    Most Tweeted This Week

  • NPHHaru

    30fps is _good_. In gaming (15+ year engine dev here) we try to lock the FPS at a reasonable rate, sure it _can_ go faster, but if it never falls below 30fps when scrolling, etc… it will feel smoother than an unlocked display doing a mix of ‘mid 40′ or ‘mid 50′ fps. fps jitter looks _awful_ to the eye. The number (30) is well above required to feel smooth. Any more isn’t useful, this is just ignorant number slinging.

    • http://www.technogasms.com Sean Riley

      There’s been a good bit of arguing going on at XDA over whether this is perceptible or not.

      I’m certainly in agreement with you that the number isn’t important as long as it is moving things along fast enough that the users aren’t noticing any hiccups.

    • http://Website Jonathan

      I agree that “jitter” is bad, and that we can often distinguish changes in fps, where a standard speed would not be as bad, however I would disagree that 30 fps is fast enough.

      Regardless of whether the intent is to “fix” the fps or not, certain variability will occur. And 30 fps is slow enough that you can still make out the shots. It’s purely an internet myth that we can’t distinguish 30 fps. We can and do. And when it drops to 28? Absolutely visible. I’d say google is right on with standardizing 60. That way just a little lag will still keep things in reasonable ranges.

      • http://Website Derek

        It is NOT a myth, anything over 24fps and the human eye cant distinguish.

        • http://www.technogasms.com Sean Riley

          Not true, we can distinguish up to 60 fps and a little bit beyond that.

        • http://Website Metathias

          Just a little bit of looking will help you see how incorrect that statement is. The so called framerate of the eye is highly variable, taking into account focal point, eye center (fovia region) so on. With reality in mind, The higher you can get both the refresh rate of the display as well as the framerate of the image the better. There is so much information to take into account concerning this topic you could write a book on it. And people have.

          • http://Website Jason

            24fps is for recording of analog motion, ie film. Computers generate and display one frame at a time, one after another. It’s not a recording of an analog event like real life. The two are not equal. This puts the requirement of the perception of smoothness at 60 fps for computer generated animation. However, it is generally acknowledged that 72fps is the minimum threshold that computer generated animation is perceived as smooth by everyone who views it.

        • http://Website sdjkladjf

          It is no myth, watch a 60fps hdtv for a while then watch a 120fps. It’s like night and day in how much more real and smooth it looks.

  • geekster

    I just ran it on my N1 and achieved a 59..and it’s not been turned off in 3 days.. so 30 doesn’t sound too good to me…but who knows!

  • http://www.theinformnation.com Eric

    Got the HTC Incredible and used the FPS2d app.

    My results…

    avg=57 stdev=10.19
    1000 iterations

    Glad to see HTC/Google kept their word with the DINC

  • http://Website Hans

    Droid:
    Avg: 61
    Stdev: 2.61

  • http://Website matt

    HTC Hero result : 57fps

  • http://Website Wheezy

    HTC Desire

    59 and 9.4

  • http://www.anasqtiesh.com Anas

    Evo owner here, I haven’t tried heavy gaming so I can’t speak for that, but I definitely noticed hiccups when trying to scroll down a long menu quickly. It’s not annoying per say, but it’s definitely not smooth sailing as one would want from a device with high specs as this one. I hope they fix this soon.

  • http://Website Joe

    MyTouch 3G Slide: 60fps

    • http://Website Joe

      …with a stdev of 6.74

    • http://Website plainbrad

      My mytouch slide tested about the same

      61 w stdev of 7.29

  • dawkins20

    Nexus One
    Done avg=63 stdev=2.04
    1000 iterations

    What is stdev, is lower better?

    • http://Website Helmore

      stdev stands for Standard Deviation. Lower is better in this case as it stands for how much it deviated from its average frame rate.

      • http://Website Sleepthieves

        Your right, I didn’t realize it meant deviations from avg frame rate. I figured it was of the total tests of all users so far and their avg fps.

      • http://www.technogasms.com Sean Riley

        My math skills aren’t stellar but Helmore is right on both counts.

        It’s interesting that your standard deviation was so low, the app designer and most of the results reported here suggest a std. dev. of around 10. Had you recently rebooted your phone?

    • http://Website Sleepthieves

      If I’m not mistaken it stands for standard deviation. http://en.wikipedia.org/wiki/Standard_deviation
      Basically your are in the 2nd deviation (2.04 to be exact). Problem being, we don’t know what kind of curve their statistics creates. If it was a bell curve, which would not be surprising as many things have a bell curve, then you (63fps) would be in the top 2% of all devices (individual results) they have statistics for. Oh and to answer your question directly higher is better in this case. Take this with a grain of salt i cant be certain to what they are referring to with their statistics but this was my guess.

      • http://Website Derek

        WRONG! His score is 63fps with a standard deviation is 2.04, that means 68.2% of his tests resulted in frame rates that were within 2.04fps of his 63fps score. Learn some statistics before coming in here posting garbage. You even linked the wikipedia reference and they had it correct and you still got it wrong.

  • http://Website catalyst

    droid incredible
    avg= 56 stdev=10.77

  • http://Website matt

    Nexus one got 56fps

  • http://Website TT

    G1 Tmobile 2.1
    Avg= 60
    stdev= 4.41

  • http://Website Chris

    Eve
    Avg=28
    stdev=5.91

    • http://www.technogasms.com Sean Riley

      So your figures match up, but in practice are you noticing the slow down?

  • http://Website tim

    1st Gen mytouch cyan mod 5.0.7 no task killer w/ overclock widget, reboot everyday

    Avg: 54 fps
    Stdev: 9.92

  • http://Website Inspiron41

    seriously why dont these ppl employ and paid some of these xda developers? seems like the xda community always have a solution

  • http://Website MTSlide

    Slide –

    Average – 61
    stdev – 6.36

  • http://www.typhon4android.org/ Mike Leahy

    Is LOLing.. You guys now are reporting this? ;P I brought it up as long as 2 weeks ago in comments on A&M; that’s right ignore the fanatical dev (oh the sky is falling!).. ;P It’s such a glaring issue that the moment I ran my simple 2D test and saw the improper capping I immediately ran my simple 3D test and jaw dropped as that was the first improper capping I’ve seen on an Android device for OpenGL ES.

    It’s a straight up defect as the Nexus One running the same Snapdragon processor as the EVO with stock 2.1 or the FroYo RC doesn’t have this particular improper capping issue. One is smooth as butter (N1) and EVO 4G run around 30 FPS with variability as wide as 15-45 FPS on upper bounds (standard deviation 8-10 sounds about right). The G1 runs the simple test cases at 58-60 FPS.

    For those that say you can’t tell a difference all you have to do is show _anyone_ untrained or trained the N1 compared to the EVO 4G and it’s clear as day which one looks smoother and better. A simple rotating 3D cube is all it takes. But the problem is that this capping is kicking it regardless of scene complexity….

    Here is the kicker in my 3D test I can throttle the rendering speed and with OpenGL ES that means how fast one calls eglSwapBuffers. If I call it over 30hz the improper capping kicks in and here is the very strange part. If I then set the swap buffer rate to 15hz it takes 10-20 seconds for the improper capping to stop and things to lock to 15hz. If I raise the rate to 30hz it doesn’t trigger the improper capping and frame rate is locked at 29-30FPS with _no variability or deviation_. That is the crucial aspect of this test is that with capping from the software side under my control I can lock it at 30hz and there is no variability (15-45FPS) and it’s rock solid. If I raise calling swap buffers back to 60hz then the improper capping kicks in again.

    This bug if it is allowed to persist across various Android devices hurts developers and end users. Regarding developers if one only has an affected device to work with you’d likely not realize the problem. It punishes developers who are trying to write very efficient real time apps & games. As far as end consumers well you just get a laggy / lazy display and that nice GPU/CPU combo is for naught and you aren’t getting longer battery life either.

    • http://www.technogasms.com Sean Riley

      Apologies for missing out on that one Mike, I’m not going to lie you go over my head at times, but I’ll endeavor to sift a little more carefully through your sage council in the future. :)

      Your perspective on this one makes it sound far worse than I was imagining so hopefully the hue and cry gets HTC’s attention and they correct this on the Evo and don’t make the same mistake again.

      • http://www.typhon4android.org/ Mike Leahy

        aww shucks.. I do get a little spirited in my debate at times and the tech stuff comes out naturally.. Heh heh. I was trying to be funny / tongue in cheek sarcastic about the “ignore the dev part”, so no worries.. ;P

        I really wanted to make a video back when I first saw this problem though I’m rather determined to launch TyphonRT in July, so didn’t follow through on a video. Kind of bummed I didn’t now that the story is getting more play than the Droid 2.1 update improper 2D capping which is likely the same or closely related issue. The top post in the XDA dev forum on the EVO 4G post links to my 2D test and lots of folks are checking it out again (which is good!).

        The EVO 4G issue is even more pronounced and awkward when you see a video of the N1 running at full speed and switching the swap buffer rate to 15hz and the N1 will lock right to 15hz immediately. This compared to the EVO 4G that takes 10-20 seconds to switch to 15hz when the improper capping is kicked in. So it’s really odd to see the redraw rate stay well above the rate it’s actually being called at (15hz) from the app itself, so this really does point to an anomaly beyond normal capping. It’s almost as if whatever code path gets triggered by the improper capping that it automatically tries to take over the swap buffer process from the app itself and ignores changes for a long time even if the swap buffer rate as controlled by the app drops well below the rate that triggered the improper capping code / execution path.

  • http://Website fkillah

    58 fps 8.8 stdev on G1 stock 1.6 t-mobile (no root)

  • http://Website landykos

    Motorola Cliq..

    Rooted Running Adlxmod 0.4

    avg = 61
    stdev = 18.30
    100 iterations

  • http://extorian.co.uk/blog/ eXtorian

    30fps isn’t that bad. When you go and see a film at the movies they’re often 25fps and most people don’t complain.

    Throttling at 30fps will greatly increase battery life, and help leave plenty of resources free for background tasks.

    • http://www.typhon4android.org/ Mike Leahy

      If it was proper capping then that would be one thing, but this kind of setting needs to be user modifiable and not burned into the ROM / firmware.

      Also it is very noticeable in particular with fast moving or rotating objects. A simple 3D spinning cube is going to look much much better on the N1 at 60hz compared to the EVO 4G at 30hz. The problem is that the capping is leading to high variability (low of 15 high of 45 FPS) and a much larger standard deviation (8 frame above / below 30). As mentioned I can in an app manually set swap buffer rate to 30hz after the improper capping is gone and I can get the same simple scene to lock at 29-30 FPS with no deviation. So there is a problem with the capping.

      As mentioned though the easiest thing to do is to find a way to make this user settable. A button for fastest graphics performance where the user can decide if they want capping.

      Until specific metrics on how much the improper capping increases battery life one can assume it’s negligible.

      Why pay lots of money for a high end phone with the latest CPU / GPU when the G1 can outperform it (ok that is loaded; only for simple 2D / 3D scenes).

      • geekster

        Mike that is great information…but what are the “regular” end users supposed to do? This sucks

        • http://www.typhon4android.org/ Mike Leahy

          @Geekster
          Unfortunately there is nothing that can be done user side with stock ROMs as far as I’m aware. This does affect both devs and end users though so everyone gets the short stick equally. Now I unfortunately haven’t had the time to go through the very length post on XDA developers forum that discusses this issue. It has grown to over 18 pages in ~2 days, so it’s a lot to read through. From my skimming it seems folks that are installing custom ROMs are also seeing the problem and that certain combinations of overclocking and other CPU settings don’t guarantee a change either. I haven’t had time to look it over, so there quite likely is some good info in there from folks who run custom ROMS.. Here is the relevant forum post.

          http://forum.xda-developers.com/showthread.php?t=699290

          It is nice to see that the Sprint executive team contacted the initial poster and mentioned the Sprint product team is seriously looking into this issue.

          As a dev I actually try and run stock ROMs all the time to make sure I’m testing the majority experience when testing my work. I only installed the FroYo RC on my N1 because I really wanted to try the JIT and it’s awesome! :)

          I think the best way forward is for Google to build into Android a well tested capping mechanism and make it user configurable in the settings. Just like one can turn on/off GPS or 3G to get better battery life one should be able to click a button in the settings and turn on/off performance graphics (capping).

          Right now it appears it’s up to the OEM and carrier to set a parameter in the ROM / firmware that can only be modified with a firmware / OTA update. As far as I’m aware Google didn’t know HTC or Sprint meddled with this setting or were aware of the outcome before the EVO 4G launched. Though honestly the most basic 2D & 3D tests show this clearly, so I do hope basic 2D & 3D tests are added to the Android Compatibility Test Suite which supposedly has 20k tests.

          This can likely be fixed in the next OTA update for the EVO 4G and I’d gander since more noise was made this time (Engadget, MobileCrunch, A&M, Phandroid, plus other blogs) compared to the Droid 2.1 update where just Ed @ ZDNet and Phandroid had a blog post regarding degraded 2D performance in the same way (probably related) that HTC and Sprint will take this into consideration. I also see that the recent bug filed against the EVO 4G in the Android bug tracker has received over 300 star votes:
          http://code.google.com/p/android/issues/detail?id=8942

          So if you have a Google account head to the link above and simply star it even if you are just a user and not a developer. That will be one way to make sure the powers that be realize this is a priority issue. Unlike other bugs that have languished unlooked at for 6+ months in the bug tracker this one has been immediately assigned as a defect. Emailing Sprint & HTC customer support is a great idea too. They are aware of the issue, but the more email they receive the more they will take this seriously.

          Also this is not a catastrophic failure of the EVO 4G hardware and it should be corrected most likely in the next OTA update. So hang in there. Those that bought the EVO 4G got a great device and it will perform better shortly.

          • geekster

            Thanks again mike! I already starred it and emailed HTC. Hopefully you’re right and this gets fixed with the next OTA.

          • http://Website Antonio

            Mike, will you be my best friend? Man, hearing someone not freaking out is refreshing. The Dev community needs to be listened to more intently. It was not an issue for me but I would like my EVO to perform as well as the Incredible.
            Seems reasonable, The are both awesome devices, with similar specs, no?

            Either way Bro I’d love to buy you a beer (today would be a great day, USA VS ENGLAND at a British pub no less) if you are ever in Monterey know got a friend. We need to reward guys and gals like you.

  • http://Website Albert

    Sprint HTC Hero 2.1 52-57fps

  • Dave K

    HTC Hero (Sprint):

    Average – 59
    Standard Deviation – 8.08

  • http://Website zedklind

    g1 on 2.1 xtreme
    58 avg / 7.85 stdev

  • http://Website watbetch

    MOTOROLA CLIQ, rooted and locked at 528Mhz on KB7SQI 1.4.8

    -Avg=75
    -stdev=4.37

    • http://www.technogasms.com Sean Riley

      Whoa, interesting outlier. I wonder what is causing your spike.

      • http://Website watbetch

        Well here is another one I just ran.

        Avg=74
        stdev=8.13

        One moar
        Avg=74
        stdev=8.36

        once moar
        Avg=75
        stdev=7.76

        • http://www.technogasms.com Sean Riley

          Definitely convincingly consistent, hell of a rom you have there then as the other Cliq user was reporting results in line with everyone else.

          • http://Website watbetch

            Yeah I’m extremely happy with this rom. I have the Genie Widget(news&weather), Tweetcaster, MOTOBLUR with a couple of it’s widgets, Google Voice and Music are all running the background 100% of the time along with the other standard junk like Calender/Text Messaging/News so I’m very happy with the results I’m getting.

            It’s not a stripped down rom either though. myFaves and some other T-Mobile junk is removed but it still has some extras

            KB7′s rom for the CLIQ is probably the best one available, the other CLIQ reported here was running something else that’s newer

            One moar for good measure
            Avg=75
            stdev=5.38

  • http://Website Terrell

    After 3rd test on rooted G1
    Done avg=55
    stdev=13.49
    1000 iterations

  • http://Website realmrealm

    Just posted on Google Code – Android:
    http://code.google.com/p/android/issues/detail?id=8942#c79

    “”
    Got a call from the Dan Hesse’s Office(CEO). Here’s what happened:

    1. Sprint has reached out to HTC about this issue. They acknowledge the problem and said they are working on a Firmware update that will address this. However, they could not give us an exact time frame.

    2. The engineer at HTC encouraged us to go to HTC support and send emails to them about this issue so it gets more attention internally, and hopefully speed things up.

    Also, I asked her to relay a message to Dan Hesse, Saying that this might not seem like a big deal at first, but it is in fact a huge one. Customers, especially those coming from an iPhone, expect their phones to “just work”, and even if they don’t notice it at first, that 30fps cap will get them frustrated at some point, and they will erroneously attribute it to developer, the phone or Sprint, hurting everyone in the process.

    She also said Sprint wants this resolved, but they are pretty much at HTC’s mercy right now.

    Alright boys and girls, it’s time to bother HTC!

    Visit HTC support here:
    http://www.htc.com/us/support/e-mail
    and send your Email to them.
    At this time I would advise against sending “template” emails because once they start receiving several of the same they can just filter them out. Remember, they are a huge company, they have the tools. Speak with your heart this time.

    THE GUY AT HTC STATED HIMSELF THAT THIS WILL BE THE QUICKEST WAY TO GET A FIX. LETS GET ON IT!
    “”

    Hope that helps shed some light.

  • http://www.typhon4android.org/ Mike Leahy

    On the Android bug tracker for this issue someone posted this response that apparently is from HTC customer support:

    ———-
    I understand that you have concerns about the EVO 4G with Sprint
    running 30 FPS. We apologize that you are not satisfied with the FPS
    on the device, this is actually how the phone was designed to work.
    This was a decision made to enhance overall performance of the device,
    and also to enhance battery life. This may be further enhanced in a
    future update, but at this time I can neither confirm nor deny this.

    When an upgrade for a device is released, it will be announced via
    Twitter, Facebook, and our own HTC.com. You may also be notified by
    your network provider, which in this case, would be Sprint.

    Thank you for interest in HTC products! I would like to take this
    opportunity to encourage you to take our Customer Service Satisfaction
    Survey at http://survey.htc.com/worldwide. This lets my boss know how
    I’m doing, and also helps us improve your Customer Service experience.
    I look forward to hearing your feedback about our interaction!
    ———-

    This is really a bummer. As the capping implementation is piss poor and very sub standard. I will be making a video soon to show precisely why it is so flawed. Basically this issue really drops my confidence in HTC technical decision making. There are absolutely no metrics supporting that this improper capping helps battery life; I assume it actually hurts it really or does nothing. My real time app is still chugging along calling eglSwapBuffers at 60hz and doing it’s thing. The fact that under the hood there is an alternate code path that gets engaged (mind you not an Android proper code path either) probably doesn’t even help with battery life.

    Simply put Sprint and HTC themselves realized they had a huge battery drainer in the EVO 4G and are grasping at straws to try anything to improve it. They crippled the device and as I said unless there are clear metrics provided it’s highly likely that this crippling does not improve battery life.

    Hrrrmmm… So this is not a Google issue or Sprint issue. Spring may have leaned on HTC for better battery consumption, but HTC screwed it up big time.

    Again I’ll make a video that clearly shows improper capping.

    So for folks with the EVO 4G continue to make some noise by sending HTC emails and continue to star the bug in the Android bug tracker. It is now the 3rd (soon to be 2nd highest) defect in the tracker. Everyone has done a marvelous job in the community raising their voice on this one!

    As mentioned I think this is something Google should take note on and build into Android a _proper_ capping mechanism that is user controllable from the settings. Leaving it up to HTC and other manufacturers to badly hack Android in regard to this matter is not working out so far.