12
Jul
Jelly-Bean-Logo_thumb1_thumb_thumb
Last Updated: August 10th, 2012

Welcome back to GTKA, everyone's favorite investigative series where we learn all about the newest version of Android (with a heavy emphasis on "all"). The previous two episodes, if you didn't catch them, are here and here.

Today we'll be doing something a little different and looking at something near and dear to everyone's hearts: performance. Jelly Bean is crazy fast. Slap it on a Galaxy Nexus and it'll feel like a brand new phone. Scrolling is faster and smoother, and the touch response is hyper-sensitive. In addition to all the smoothness work, there are new transitions all over the place.

I'm sure you've all seen a sweeping overview of this, but those are boring. What exactly is new, and how did they do it? That's what we're here to figure out. So, grab your popcorn, kids; it's time to learn all about Project Butter.

How They Did It

So how do you make an 8 month old Galaxy Nexus run like a Galaxy S III? Lots of hard work. Hard work that was thoughtfully detailed to us at Google I/O by two of my favorite I/O presenters, Chet Haase and Romain Guy. An hour long PowerPoint presentation geared towards developers is not the most accessible thing in the world, so I'm going steal some slides and try to cover the more interesting parts, and (hopefully) condense it down to a few minutes. Doesn't that sound like fun?

VSync Turns Frame Drawing Into A Well-Oiled Machine

_0006_Layer-2_0007_Layer-1

PC Gamers are probably familiar with the term "VSync." It's that graphics option checkbox that will stop your screen from tearing in a video game.

To understand what exactly VSync is, we're going to need a quick display primer: Video (ie a phone display doing stuff) is made of individual pictures called "frames." Smooth animation is usually 60 frames per second. Frames are made of pixels, and, when the display draws a frame, the pixels are filled in row by row. Got it? Good.

The display (LCD, AMOLED, whatever) gets each frame from the graphics chip, and starts drawing it line by line. Ideally, you want the display to get a new frame from the graphics chip after it is finished drawing the previous frame. Tearing occurs when the graphics chip loads a new frame in the middle of the LCD draw, so you get half of one frame and half of another.

VSync, well, synchronizes things. It tells the GPU to wait for the screen to finish its line by line drawing before loading the next frame.

Android has always used VSync to stop screen tearing, but Jelly Bean takes things a step further. The VSync pulse is now used to start all the processing for the next frame.

Most Android displays run at or around 60 frames per second (or 60 Hz, in display jargon). In order to have a smooth animation, you have to actually be able to process 60 frames per second - that means you've got 16ms to process each frame. If you take longer than 16ms, the animation will stutter, and that buttery smooth feeling we're aiming for melts away.

16 milliseconds isn't a lot of time, so you're going to want to make the most of it. In Ice Cream Sandwich, processing for the next frame would just kind-of lazily start whenever the system got around to it. In Jelly Bean, the whole process of making the next frame starts as soon as the last frame is finished, at the beginning of the VSync pulse. In other words, they're using as much of the 16ms as they can. Here's an example:

Untitled-1

This is what life is like without running everything off of VSync. In these slides, the numbers are frames. First the frame is processed by the CPU and GPU, and, when it's finished, it's handed to the display at the beginning of the next VSync.

So in this picture, Frame 0 is displayed, and, during the 16ms of display time, the CPU and GPU prepare the next frame. The calculations get done in time, and at the next VSync pulse, they hand over the next frame, "Frame 1." Great.

We're now showing frame 1, and it's time to start working on frame 2. Something slows the system down, though, and processing for the next frame doesn't start until we're well into our 16ms time limit. The system now only has about 4ms to figure out frame 2, so the processing for it doesn't get finished in time. With no frame 2, the display is forced to show frame 1 again, for another 16ms. Team Android has dubbed this "Jank," and it basically means any animations happening during this time won't be fluid; the user will see stuttering.

_0003_Layer-5

Here's the new way of doing things in Jelly Bean. All the processing for the next frame starts at the VSync pulse, so you're now making the most of your 16ms of render time.

Frame processing has moved from "Yeah whenever we get around to it," to a rigidly scheduled, highly organized affair. Sort of like the difference between a car mechanic and a NASCAR pit crew. In this example, all the processing happens within the 16ms time limit, all the frames get delivered on time, and you get a smooth, buttery experience.

Triple Buffering Stops Jank From Snowballing

VSync isn't the only thing that helps out animation smoothness, Android is also able to recover from a slowdown more smoothly.

_0002_Layer-6

So what the heck is a "buffer"? Put simply, a buffer is the container the frame is built and stored in. We've been referring to frames by number, but really, those frames sit in one of the two buffers. Android is double buffered, a pretty typical setup, meaning it can display 1 frame while working on another. In this picture the buffers are labeled "A" and "B."  While displaying buffer A, the system starts building a new frame in buffer B. When that's ready, they swap buffers. B gets displayed, and A gets cleared and a new frame is worked on.

_0001_Layer-7

The problem with double buffer arises when you take longer than 16ms to draw your frame. Here the processing on buffer B runs over, which means a stutter (Jank!) happens. Stuttering is bad and all, but the real problem here is all the white space in the CPU and GPU graphs, that's wasted time. In the first frame, buffer B runs over, so that buffer is in use until it can be displayed, buffer A is also in use, because it is being displayed for 2 frames in a row, and remember, you can only switch frames (and hence, buffers) at the VSync pulse. The CPU and GPU are out of usable buffers, so they just sit there. One slowdown puts the system behind, which causes more slowdowns. This was how Ice Cream Sandwich worked.

_0000_Layer-8

In Jelly Bean, we've got a solution for 2 full buffers, a third one! Same situation as before, buffer B takes too long, and A is in use displaying the current frame. This time though, instead of wasting processing time during the repeated buffer, the systems creates a C buffer, and gets to work on the next frame. Triple buffering stops the stutter fest, and after the initial skip, the user sees a smooth animation. It's all about presenting a stiff upper lip to the user even though things aren't going so smoothly under the hood.

So why don't they just do triple buffering all the time? Well, as you can see from the diagram, triple buffering introduces a bit of input lag into the process. Look, for instance, at the distance between the rendering of buffer C (the blue/green part), and the displaying of it. So, when things are misbehaving, you get a choice of 2 evils: input lag (your touches taking longer to have an effect) or choppy animation.

To address this, Jelly Bean doesn't do triple buffering all the time. It normally runs a double buffer, but that third one is around whenever you need it. This way you get less input lag, and when things go wrong, you've got a third buffer at the ready to help you recover.

The Results

The result of all this hard work is buttery smooth animation. The team was so impressed with their new animation aptitude that they spruced up many of the transition animations, which I will now present to you in excruciating detail. Check out ICS vs Jelly Bean, in super slow-mo.

New Animations

Icon Launch Transitions - Left: ICS's no-frills app launch transition. Right: JB zooms in from the location of the icon

There isn't much to say about these videos, but I'll try my best. Ice Cream Sandwich (left) has an absolutely boring icon launch transition. It's just a simple stretch and fade to the center of the screen. In Jelly Bean (right), applications zoom out from the icon position. This manages to be both neater looking and more communicative: "You pressed this icon, and this is opening from it." I like it.

Uninstalling - Left: ICS just uses the standard screen transition. Right: Jelly Bean's fun "toilet flush" animation

Uninstall gets a cool transition too. It's a slide/fade/shrink animation to the bottom of the screen. It sort of reminds me of a toilet flush. The previous screen also gracefully slides into view when the app is gone.

Launching from within an app - Left: ICS does a simple fade. Right:  JB slides things all over the place.

This transition is pretty much the uninstall animation in reverse, and it is used all over the place. I think it's triggered whenever an app opens another app. So here, you see the play store launching an app, and you'll see it when something like Google Reader launches a web browser, it's all over the place.

Update: Googler Clarification!

The always-helpful Dianne Hackborn, an Android Framework Engineer, stopped by our Google+ page (you are following us on G+ right?) with some insight on this animation:

"One thing I'd like to clarify -- the "uninstall" and "launch" animations are actually the same thing. This is the animation set for a "task switch". That is, moving in the UI from one task to another. A task is the thing you see in recent tasks, so this effectively tells you that you are moving between tasks that would be seen in the recent tasks UI."

So there's even more communication through animation. Thanks Dianne! <3

Recent Apps - Left: ICS oddly fades to a blank desktop. Right: JB's awesome transition

Recent apps probably has the coolest animation out of the bunch. The app grows out of the thumbnail, which is, again, neat looking and communicative - the perfect use of an animation system like this.

And finally, the new Jelly Bean camera animation. Snapping a picture sends your still flying off to the right, and a swipe will bring it back. I didn't bother showing you the ICS version because, well, nothing happens.

That's about it for Project Butter. You really have to experience it to get the full effect. Everything is smooth and fast. It really is impressive how much more power they've managed to squeeze out of my old Nexus.

Ron Amadeo
Ron loves everything related to technology, design, and Google. He always wants to talk about "the big picture" and what's next for Android, and he's not afraid to get knee-deep in an APK for some details. Expect a good eye for detail, lots of research, and some lamenting about how something isn't designed well enough.
  • http://www.androidpolice.com/ Artem Russakovskii

    Sweet writeup. Will you have my babies, Ron? Or if not, will you be my babies nanny at least? I need a techie ninja nanny.

    • http://www.facebook.com/SinCityFX4 Jeremy Cope

      Awesome

  • Joshua Sutton

    Is it just me, or does it seem to take longer, despite the coolness of the transitions?

    • Zacisblack

      He slowed it down in developer options. You can actually make it faster than stock by setting it to ".5X". You can go all the way up to 10X which is probably what he did.

      • Ron Amadeo

        Exactly right ^

        At 10x you might see a 1 second difference, at full speed, you won't see a difference, but if you're a speed freak you can speed them up or turn them off.

        • http://www.androidpolice.com/ Artem Russakovskii

          Pretty sure that's not what Joshua was asking. He was comparing animation start and end time in ICS and JB, and ICS would end up showing the final app sooner, even with JB supposedly reacting to the touch faster.

          • Ron Amadeo

            I know. He's right, ICS may be a second faster in some of these videos, but the animations are slowed down, so any difference will be exaggerated. At full speed, the difference is negligible.

          • http://www.androidpolice.com/ Artem Russakovskii

            But shouldn't it be faster in JB? They're slowed down by the same factor, so JB should finish first from the push of the button ideally. The problem is the animation itself is longer, so it's really fine. A good comparison would be the same animation - that would show how much faster JB is.

          • http://ashn.myopenid.com/ Ash

            It's not just about fast, ICS is pretty fast, it's also about smooth now.
            Butter smooth.

          • Simon Belmont

            Yes. JB's animations would technically be slower than ICS' animations even in real life speed.

            I think Ron is basically saying that the difference is negligible in practice. It's just very apparent when slowed down.

        • Simon Belmont

          I'll admit. I think I actually like the ICS animations more than the JB ones. They were more subtle, but I liked the stretching and morphing in that they did. That being said, I haven't used JB in real life yet.

          I got really used to the ICS animations using CyanogenMod 7.2 (which has them back ported) when messing around with my wife's EVO 4G. They are just very visually appealing to me for some reason.

      • oneillperson

        Can this be done in stock Android 4.1? Or does it require a custom ROM?

        • Ron Amadeo

          It can. Settings -> Developer Options -> look for things that say "xxx Animation Scale".

          4.0 has 2 listings and 4.1 has 3, so I'm going to assume you can slow down some things, but not as many as you can in 4.1.

    • http://www.facebook.com/profile.php?id=645454807 Varun Nanda

      The animations are considerably slowed down so that we can see them clearly. Its not the problem of the OS.

  • RedPandaAlex

    Now if only this would get pushed to my unlocked Gnex. You know, I haven't pressed "Check Now" for a whole five minutes. I should go do that.

    • http://www.androidpolice.com/ Artem Russakovskii

      Why not just update it yourself?

      • http://www.facebook.com/Trisjen.Harris Trisjen Harris

        That's what I just did, I couldn't wait any longer. The more I pushed check now, the more I got impatient!

      • RedPandaAlex

        Because I'd have to unlock the bootloader, which would wipe my device (i think)

        • fixxmyhead

          backup ur shit to ur comp and stop being lazy

        • http://www.androidpolice.com/ Artem Russakovskii

          Indeed. That's why you should do it from the get-go :)

        • duplissi

          No there is an app that can lock or unlock the boot loader from within android

        • Erythnul

          Not necessarily. If the stock recovery on the Gnex works like the stock
          Nexus S recovery, you can easily flash signed packages (ie OTAs).
          Just
          download the package (you may need to rename it to update.zip, not
          entirely sure, it's been a while, you might want to google it) and flash
          away! :)

          I hope you'll somehow read this ;)

    • clifford Rosenberg

      I literally just got the update. I saw a notification popup on my screen, and I was like "NO WAY!" I was going to manually update too, but I just hadn't gotten around to it; that sure saved me the trouble.

      • wickets

        good article and off topic uber jealous of the update

      • Michael

        Some tip to push the OTA faster??

    • PhilNelwyn

      My 4.1 takju received the 4.1.1 OTA roughly at the time you wrote this.

  • http://twitter.com/TKfromCLE Terry Kessler

    The "Getting to Know Android x.x" series is like the "For Dummies" book that never was. Well written and explains all the new features quite nicely.

    • RedPandaAlex

      Agreed. There are a lot of Android news sites out there, and features like this set Android police apart

  • Nate

    Great article!

  • http://twitter.com/bongizmo bongizmo

    Did you just call the Galaxy Nexus "old"? :-)

    P.S. Great write up.

  • clifford Rosenberg

    A little off topic, but I was messing around with the newly installed JB on my phone and I noticed that under Phone Search, there's no longer an option for searching my text messages. Was that taken out because of the Apple lawsuit?

    • Simon Belmont

      Yup. Universal Search was taken out because of an Apple patent.

      Hopefully, it's struck down so that it can be put back. Universal Search is useful.

  • Mike

    So would you say the Galaxy Nexus running Jelly Bean is faster than, or just as fast as the Galaxy S III?

    • Ravengenocide

      Saying that it's faster than SGS III is an abuse of the word "fast" in so many ways. It's not faster, might seem to be faster neglecting any actual speed, but it's not.

  • ConCal

    I Love this series!!! keep it going!

  • jak3072

    great write up & excellent videos

  • mike16

    old nexus ? Seriously ? That phone is barely 8 months old! In many parts of the world it hasn't even been launched yet!

  • Tarek El-Ghazaly

    Great article guys. Love the videos too. A lot of thought has gone into this, and this is why AP articles are trending everywhere.

  • http://twitter.com/thepowerofscott Scott Nienhuis

    The only thing I dislike about this series is that I'll have to wait another 8 months or so for the next edition (Re: GTKA Key Lime Pie?) once you're done breaking down 4.1 for us :(

  • Vu Viet Anh

    Android - making iOS looks like a joke ever since it comes out.

    time for another Android Vs Apple render.

    /i want JB so bad.

    • http://www.facebook.com/alexbin.zhao Alex Bin Zhao

      Android is a joke, my 3 months old htc one x become outdated or old just as this article said.
      Why couldn't google engineers get this simple thing done 6 months ago with ICS

  • Simonsays

    Please link to Google I/O sources, from which the technical information was derived, otherwise this is a thinly veiled attempt at soft plagiarism.

    • http://www.androidpolice.com/ Artem Russakovskii

      He did link the source used.

    • Ron Amadeo

      Try the first paragraph of the technical section:

      "Hard work that was thoughtfully detailed to us at Google I/O by two of my favorite I/O presenters, Chet Haase and Romain Guy. An hour long PowerPoint presentation geared towards developers is not the most accessible thing in the world, so I'm going steal some slides and try to cover the more interesting parts, and (hopefully) condense it down to a few minutes."

  • http://twitter.com/havens1515 Randroid

    I think I missed part 2 of this. Can we get links to the previous parts at the top? That would be sweet.

  • http://twitter.com/havens1515 Randroid

    The double buffering that becomes triple buffering when necessary... that's awesome. As someone who went to school for computer engineering, I can really appreciate what they're doing there. Timing is always a tough thing to deal with, and they came up with a really sweet solution that works well for both possible issues.

  • Larizard

    Great read, especially the part about the the triple buffering. But I wonder, what is it in Project Butter that, according to the keynote, allowed Jelly Bean to "predict where the user will press next"? I don't know if you intentionally left that out, or that was just a very loose description of one of the processes you explained.

    Thoughts?

  • http://btwnworlds.tumblr.com/ Lou G

    i cant wait for my nexus 7 to ship. I sold my ipad for it and those animations look amazing

    • http://twitter.com/PierreJIskandar Pierre J. Iskandar

      This == Ultimate win.

  • JustTrollin69

    That was a very good write up, thank you for that.

  • CT

    Great and very detailed review! Looking 4ward to using JellyBean !

  • Simon Belmont

    Love your posts, Ron. Always very detailed and technical, which is right up my alley.

    While technical, you also manage to explain it well for the less technical person. Well done.

  • http://www.facebook.com/people/Vanessa-Deagan/1842826468 Vanessa Deagan

    "Everything is smooth and fast" - this simply isn't true. While it's a vast improvement, there's still plenty of janking, like when I scroll around this page. I've noticed jank always occurs during lazy loading - network requests block the main UI thread for some reason.

    It's definitely better/smoother and does make Android feel more refined, but please keep it real. It's far from perfect, there is much room for improvement.

  • Gobletsky

    Awesomely written. Thanks
    Just one question, Is tripple buffering and vsync hardware oriented?
    Can MUCH older phones(having arm7 & adreno 200) support it.

  • http://profiles.google.com/dangerismymiddlename.com Paul Danger Kile

    Thank you!

    I thought that I was happy with ICS, but for sure there are programs that I use today that will benefit from JB.

    I think that 60 fps is necessary for gaming, because acheiving that rate, means that there's enough headroom to make the video, AI, controls, etc, also run smoothly.

    Smooth animation requires only 30 fps. Your local cinema is getting away with 24 fps, because film sources have motion blur to smooth the transitions.

    That said: I agree, we really want to achieve at least 60fps for games.

  • Aaron

    Does this improve scrolling text? ICS still looks really bad

  • Androidisthebest

    Looks like JB is just not displaying as many frames. Very stuttering. More Google BS! 60 fps, more like 10fps!

  • Michael Zucchi

    Err, so they've finally caught up with hardware and software from 1985 at last? Yay? At long last perhaps. Triple buffering was a common technique used on Amigas when memory allowed. It wont prevent timing glitches, but it does prevent the 1/2 fps slow-down when you're just missing.

    And the whole "we only use it when we need to" is the only way it can possibly work - otherwise you don't have any 3rd buffer free when you do go over-time later.

    The JB animations are noticeably longer and more in your face - a big step back from ICS even if they are supposedly running smoother.

  • vijay

    any change about battery life and performance ? please update. due to vsync i hope battery life is not affected. Great efforts by Google. Thanks to google for such a good OS. Only thing bad about android is it is not native and based on JAVA concepts. Which is real bad. Still good.

  • ashim888

    Awesome Article

  • GraveUypo

    in the end i hated project butter. all it did to me was introduce a huge input delay.
    games like glow hockey are almost unplayable thanks to this shit.

  • Reddy

    HI Ron,

    well said mate!!! i've a query regarding vsync.....
    i)can you give me the code snippets where vsync is enable and disable.

    ii)When vsync is used(in the code).
    iii) If we use vsync will it consume more current for playing the videos???

    Thanks in advance.

  • Netwern

    Your last sentence -- actually Galaxy Nexus is not old at the time you posted this article. it was just 8 months old.

  • v

    This section might be hidden on some phones, but it’s very easy to access. On many phones, you just have to open a certain page in the settings and tap a button seven times. Use Google to figure out how to enable Developer options on your phone if it’s currently hidden (for example, search “enable developer options HTC One”).

    Once you have access to Developer options, simply scroll until you find the following three settings, which may be located on the main screen or within an “Advanced” subsection:

    Window animation scale

    Transition animation scale

    Animator animation scale

    Tapping each of the three aforementioned settings will reveal that it’s set to “1x” by default. If you want to speed up your phone or tablet dramatically, simply change each of those three settings to “.5x” — that’s it.

    Just as iOS 7.1 completely changed the feel of the iPhone user experience by speeding up transitions, this will do the same for Android devices. Adjusting these settings also shouldn’t really have any impact on battery life, though if you’re using an older phone with a slower processor you may see some choppiness.