Back at Mobile World Congress, both Anand and I heard rumblings that UI performance would be a huge emphasis in the next major release of Android. I remember being told that the goal would be to make performance smooth as butter, everywhere. Today, Google has made that official with Android 4.1 Jelly Bean, and Project Butter. 

There are a number of improvements we're going to be going over in detail soon, but probably the most visible to end users will be those improvements to UI performance with butter. Google mentioned three key things - changes to Vsync, triple buffering (which was not enabled for the OpenGL ES UI render path in the past), and improvements to the CPU governor. The end result is that the SoC will change perf states based on touch input to dramatically increase touch responsiveness. 


Comments Locked


View All Comments

  • KitsuneKnight - Wednesday, June 27, 2012 - link

    Dropping a few end user features is definitely far better than dropping ALL end user features (the result of lazy manufacturers that EoL devices shortly after release).

    Some of the Android hardware diversity is nice, such as being able to select the physical size of the device (although all the current flagship Androids seem to be 4.5"+, which I find to be too large), but the vast majority is redundant and pointless. Manufacturers just releasing phones that are largely the same as all the rest, but with very minor differences (and often with standard features missing... like how many variants of the Galaxy S lacked an LED flash!).

    As an app developer, I prefer the homogeny of the iOS ecosystem. If I was writing, say, a game, I could pick the 3GS as my minimum baseline (since it was the first to support OpenGL ES 2), and then optimize for that. That would give me a huge number of supported devices that would be /at least/ as fast. If I wanted to go wild, I could throw in extra graphical effects for the 4 and 4S. Throwing in the iPod Touches wouldn't be much extra work, as there's only a few additional variants, all of which are decently similar to one of the iPhone models.

    With Android, I couldn't do such an easy distinction. The environment becomes much closer to being 'PC-like' (not knowing anything about the target system) instead of console-like (knowing exactly what the hardware will be), which makes optimization far, far harder. Having a huge number of possible resolutions, in addition to aspect ratios, in addition to physical pixel sizes, it makes things more difficult. Certainly not impossible, but it means I'll have to waste more time on layout (especially when not using OS provided controls, such as in a game). Don't forget SoC/RAM differences.

    Personally, what differentiates iOS 4 from 5 from 6 to me are the APIs/functionality provided to developers. As a developer, if iOS 6 had an awesome new API, I wouldn't need to be worried that it'd be many months before any sizable chunk of users had adopted a version of the platform that supported that functionality.

    This is unlike the situation with Android (not sure if the official Android site still has the numbers, couldn't find them with their redesigned site), but where, over half a year after its release, 4 still has single digit adoption. If I'm reading this graph ( correctly, a much larger percentage of /active/ devices are on 2.1! (looks just shy of 10%) To say nothing of Froyo! That means that about 30% of the /active/ (still regularly checking Play) devices out there wouldn't even support the Gingerbread-required APIs. Shims will only get you so far.

    Sadly, manufacturers don't seem to care, regularly releasing devices that ship with outdated version of the operating system (a couple weeks back I saw a commercial advertising a phone that was touting how it came with GINGERBREAD), without much intention of ever updating them... I have to wonder what percentage of Android devices, when they're first released, include the then-current version of Android (only down to a named-version resolution). Unless it has 'Nexus' in the name, it doesn't seem all that likely.
  • bjacobson - Wednesday, June 27, 2012 - link

    They've said it's a high priority every previous release. Here we are, still hitching along because UI rendering happens in the main app thread...
  • augiem - Wednesday, June 27, 2012 - link

    Wow. I would laugh if it weren't so sad. I seriously can't remember a single android release where this hasn't been the big promise. I'm tired of hearing the same empty promises. What's with constantly stringing eveyone along, Google always playing the same old tune? The only reason the new crop of stuff is working a lot smoother is due to brute forcing it with faster and faster processors.

    I sure hope Windows phone gets better hardware soon (and they make some other necessary changes to the OS too). There's something to be said for an OS maker that ACTUALLY MAKES their OS instead of rebranding off-the-shelf open source crud. Android 4.0 is okay (yes, I use it on my tablet), but still not great.
  • mpschan - Thursday, June 28, 2012 - link

    Animations on my phone noticeably improved when I went from Gingerbread to ICS.

    So no, it's not because the processors are faster; they have made actual improvements in UI smoothness w/o relying on faster hardware. That doesn't mean they can't continue to improve with each generation.
  • winterspan - Monday, July 2, 2012 - link

    "Animations on my phone noticeably improved when I went from Gingerbread to ICS."

    The reason for that is because Android *finally* implemented hardware accelerated rendering of the GUI (since almost all modern ARM SoCs have a GPU) in Honeycomb/ICS.

    That said, it is still not perfect as shown by Googles recognition of "lagginess" as a problem and attempted correction with Butter.

    In comparison, the five year old iPhone 2G had very smooth and responsive scrolling and panning performance, despite its 412mhz ARM11 processor and 128MB of ram due to the optimized openGL rendering of the GUI (even with a very slow by todays standards PowerVR MBX Lite GPU)
  • Ryan Smith - Wednesday, June 27, 2012 - link

    I'm curious to see what exactly Butter entails. As any gamer will swear up and down, triple buffering is extremely nice, but it's not the solution to keeping your UI at 60fps (16ms). TB is what saves your hide when you've already blown your rendering budget.
  • HisDivineOrder - Thursday, June 28, 2012 - link

    It's good that Google's hitting all the points they need to. They have a few problems and they're addressing the ones they can.

    1) Fragmentation. They're hitting that by offering a standard for tablets (Nexus) that will encourage other Android makers to at least hit that point if not exceed it.

    2) Improve responsiveness. If the display is the window into the whole platform, the responsiveness is a big indicator of how you feel while using it. If it's choppy or losing frames, then suddenly you feel like you're running outdated hardware, even when you're not. Making everything smooth helps make everything feel better, even if in reality it's really no more or less capable than it was. What people are made to believe is really more important than what is true.

    3) Improve SIRI competition. Siri is a big thing, even if it's not entirely great for Apple (yet). Siri represents Apple's effort to leapfrog past Google in Search. Text search is great until suddenly you're just spouting off at the mouth whatever it is you want and the search engine is responding in your language back. Then suddenly text search is often silly for a lot of what we search for. When Google's bread and butter is search, that represents a huge shot across their bow. They must respond and they must have something that works as well (or better) and rapidly. Seems like they're on target to do that.

    Plus, they addressed pricing on their tablets, giving the market the tablet they've been itching for since the Touchpad firesales lit up the internet last year. Everyone thought it would be the Kindle Fire, but Amazon botched that with less than great hardware, less than great screens, and a platform approach that locked out everything Google had built up and anything Google added to the Android OS in the future.

Log in

Don't have an account? Sign up now