Google explains why Android animation speed is only now catching iOS

[youtube=http://www.youtube.com/watch?v=-F_ke3rxopc]

Fans of Apple’s mobile devices such as the iPhone, iPod touch and iPad often wonder why can’t scrolling on Android phones and tablets be jerk-free as on iOS devices. It’s been something of a mystery, especially taking into account how the original iPhone had nailed smoothness more than four years ago and on sub-par hardware which was substantially slower than the beefy chips powering today’s Android super phones.

Growing tired of misinformation about how graphics rendering works on Android, engineer Dianne Hackborn set the record straight today on Google+. Android has always used some hardware accelerated drawing, she began. “Since before 1.0 all window compositing to the display has been done with hardware”, Hackborn said.

Apple’s user interface has been hardware-accelerated thoroughly from day one, cynics might say. Truth be told, Apple designs the hardware, the chips and the operating system, allowing them to target iOS specifically for a specific CPU and GPU, a luxury Android does not have. Let’s not forget that Android does true multitasking and background processes execution, unlike iOS, which adds to the overhead. Also adding to the overhead: Native iOS apps are binaries pre-compiled for their own hardware while Android uses the Dalvik virtual machine with just-in-time compilation to run Dalvik dex-code (Dalvik Executable), which is usually translated from Java bytecode.

To be perfectly honest here, Google should be credited for treating each platform update as an opportunity to perfect the hardware acceleration features. For example, they just enabled smoother graphics in all Ice Cream Sandwich apps that rely on the new APIs.

In case you’ve been wondering, menus being shown, sliding the notification shade, transitions between activities, pop-ups and dialogs showing and hiding – Android does offload all those bells’n’whistles to the GPU. The speed of the GPU and the memory bus bandwidth directly impact the smoothness of the interface, Hackborn explained:

As device screen resolution goes up, achieving a 60fps UI is closely related to GPU speed and especially the GPU’s memory bus bandwidth. In fact, if you want to get an idea of the performance of a piece of hardware, always pay close attention to the memory bus bandwidth. There are plenty of times where the CPU (especially with those wonderful NEON instructions) can go a lot faster than the memory bus.

But the GPU “is not a magical silver bullet to butter-smooth UI”, she argues. The new Galaxy Nexus smartphone (9to5Google will be reviewing it shortly) uses a number of tricks to achieve smooth scrolling of lists, web pages and other content in apps, including turning off OpenGL hardware acceleration in parts of the interface that would otherwise cost 8MB of RAM and take away from other things, such as background process and multitasking. Provided the phone’s CPU is fast enough, it can draw graphics without the overhead of the GPU. And in the case of the Nexus S:

Nexus S has no trouble doing 60fps rendering of all the normal stuff you see in the Android UI like scrolling lists on its 800×480 screen. The original Droid however struggled with a similar screen resolution.

Summing up, hardware acceleration is not a be-all-end-all solution to the smooth user interface simply because there’s only that much a smartphone GPU can do. For example, Nvidia’s Tegra 2 GPU found in some Android smartphones can do every pixel of a 1280-by-800 screen about 2.5 times at 60 frames per second, leaving little room for complex, layered animations:

Now consider the Android 3.0 tablet home screen where you are switching to the all apps list: you need to draw the background (1x all pixels), then the layer of shortcuts and widgets (let’s be nice and say this is .5x all pixels), then the black background of all apps (1x all pixels), and the icons and labels of all apps (.5x all pixels). We’ve already blown our per-pixel budget, and we haven’t even composited the separate windows to the final display yet. To get 60fps animation, Android 3.0 and later use a number of tricks. A big one is that it tries to put all windows into overlays instead of having to copy them to the framebuffer with the GPU. In the case here even with that we are still over-budget, but we have another trick: because the wallpaper on Android is in a separate window, we can make this window larger than the screen to hold the entire bitmap. Now, as you scroll, the movement of the background doesn’t require any drawing, just moving its window… and because this window is in an overlay, it doesn’t even need to be composited to the screen with the GPU.