According to Google, the dial pad should be more responsive, call log scrolling should be “buttery smooth”, and swiping between tabs “quick and fluid”. The People app should benefit from” smoother animations and improved search performance” and the Calendar is also buttery, in the way “content fades in, animations are sprinkled throughout, and swiping/paging between days is smoother”.
(Also, as a part of Project Butter, Chrome is supposed to be optimised for “fluid” interaction with web content.)
It touches on areas such as “vsync timing, triple buffering, reduced touch latency, and CPU input boost”, which were added with Jelly Bean I (aka v4.1). The next version of Jelly Bean II (aka v4.2) saw “improvements in the hardware-accelerated 2D renderer”, designed to make common scrolling and swiping that much smoother and faster.
Also, according to Google:
A variety of WebView rendering optimizations make scrolling of web pages smoother and free from jitter and lags. Android’s Renderscript Compute is the first computation platform ported to run directly on a mobile device GPU. It automatically takes advantage of GPU computation resources whenever possible, dramatically improving performance for graphics and image processing. Any app using Renderscript on a supported device can benefit immediately from this GPU integration without recompiling (see below for more).
Of course, Jelly Bean saw a range of changes to the Android UI – all screen sizes feature the status bar on top, with pull-down access to notifications, with a new Quick Settings menu, for example – but Butter is about the behind-the-scenes-serving of such user interface elements….
Better Butter development
The inspiration for this piece was actually the presentation by Royi Benyossef, CEO of Israeli Android Association, given at the AppsWorld conference back in October 2012.
It’s a presentation well worth reviewing as Royi rattled through a whole load of performance-related Android development issues, a lot of them Project Butter related.
It seems that Google moved from using two frame buffers to using triple buffers, with the aim of avoiding ‘always trying to catch up’. And the missing of just one buffer can lead to a user perception of the system being slightly ‘stuck’ he maintained. Becoming “Janky”, in his terms. Apparently, the Butter API works on a 60FPS (frames per second) refresh rate basis using Vsync technology.
Vsync stands for Vertical Sync and is a way to “synchronize the rendering sub-system with the hardware display mechanism,” says Royi. Whereas Android had always used Vsync for buffer swapping, with Jelly Bean it also started using it for all animation and drawing requests. The Choreogpaher API, for example, new with Jelly Bean, enables you to base callback scheduling on Vsync.
He emphasises, if you work in this area, to test your app using dumpsys gfxinfo, providing a detailed profile GPU rendering, and also systrace, as well as other tools such as SurfaceFlinger, OpenGL / ES Tracer, allocation tracker, traceview and hierarchy viewer, all of which I confess to never having heard of.
As Google claims that drawing is optimised for layers, clipping and certain shapes (rounded rectangles, circles and ovals), one of the worst things a developer could do is constantly force an unnecessary redrawing of the whole display, via the View.invalidate() function. Instead, he says, you should take advantage of View.invalidate( left, top, right, bottom ) to draw specific areas. This drastically reduces the number of entries in an Event queue that have to be processed, in a timely manner of course, by the GPU.
The corollary of this is never to draw what can not be seen, an even worse use of the systems resources, which can unnecessarily load the system and make an impact on general responsiveness.
As mentioned before, Renderscript system is relevant to this whole area, promising “to offer a high performance computation API at the native level”, with you writing your code in C:
Renderscript gives your apps the ability to run operations with automatic parallelization across all available processor cores. It also supports different types of processors such as the CPU, GPU or DSP. Renderscript is useful for apps that do image processing, mathematical modelling, or any operations that require lots of mathematical computation.
In addition, you have access to all of these features without having to write code to support different architectures or a different amount of processing cores. You also do not need to recompile your application for different processor types, because Renderscript code is compiled on the device at runtime.
See a Renderscript system overview below.While Renderscript runs at a native level of operation it also needs to communicate with the Android VM, and this makes it different from a traditional Android application that just runs in the VM:
The Renderscript system adopts a control and slave architecture where the low-level Renderscript runtime code is controlled by the higher level Android system that runs in a virtual machine (VM). The Android VM still retains all control of memory management and binds memory that it allocates to the Renderscript runtime, so the Renderscript code can access it. The Android framework makes asynchronous calls to Renderscript, and the calls are placed in a message queue and processed as soon as possible. Figure 1 shows how the Renderscript system is structured.
Renderscript code resides in .rs and .rsh files in the <project_root>/src/ directory.
For more about using Google’s Renderscript, see the Renderscript Computation developer’s guide >>
More About Project Butter
For a wider spread of Butter content, see also:
KnowYourMobile.com – Android’s ‘Butter UI’: What makes it so smooth?
TechRadar.com – Project Butter