Shared publicly  - 
 
How about some Android graphics true facts?

(Edit: there have been a number of comments treating this as being written as an excuse for Android or not mattering to users or such. I'd just like to clarify that I wrote this solely to address a lot of incorrect information that I see posted around the web as truth. This is no attempt to excuse anything, and it is solely for those who already have an interest in writing and reading the often factually incorrect technical information out there.)

I get tired of seeing so much misinformation posted and repeated all over the place about how graphics rendering works on Android. Here is some truth:

• Android has always used some hardware accelerated drawing. Since before 1.0 all window compositing to the display has been done with hardware.

• This means that many of the animations you see have always been hardware accelerated: menus being shown, sliding the notification shade, transitions between activities, pop-ups and dialogs showing and hiding, etc.

• Android did historically use software to render the contents of each window. For example in a UI like http://www.simplemobilereview.com/wp-content/uploads/2010/12/2-home-menu.png there are four windows: the status bar, the wallpaper, the launcher on top of the wallpaper, and the menu. If one of the windows updates its contents, such as highlighting a menu item, then (prior to 3.0) software is used to draw the new contents of that window; however none of the other windows are redrawn at all, and the re-composition of the windows is done in hardware. Likewise, any movement of the windows such as the menu going up and down is all hardware rendering.

• Looking at drawing inside of a window, you don’t necessarily need to do this in hardware to achieve full 60fps rendering. This depends very much on the number of pixels in your display and the speed of your CPU. For example, Nexus S has no trouble doing 60fps rendering of all the normal stuff you see in the Android UI like scrolling lists on its 800x480 screen. The original Droid however struggled with a similar screen resolution.

• "Full" hardware accelerated drawing within a window was added in Android 3.0. The implementation in Android 4.0 is not any more full than in 3.0. Starting with 3.0, if you set the flag in your app saying that hardware accelerated drawing is allowed, then all drawing to the application’s windows will be done with the GPU. The main change in this regard in Android 4.0 is that now apps that are explicitly targeting 4.0 or higher will have acceleration enabled by default rather than having to put android:handwareAccelerated="true" in their manifest. (And the reason this isn’t just turned on for all existing applications is that some types of drawing operations can’t be supported well in hardware and it also impacts the behavior when an application asks to have a part of its UI updated. Forcing hardware accelerated drawing upon existing apps will break a significant number of them, from subtly to significantly.)

• Hardware accelerated drawing is not all full of win. For example on the PVR drivers of devices like the Nexus S and Galaxy Nexus, simply starting to use OpenGL in a process eats about 8MB of RAM. Given that our process overhead is about 2MB, this is pretty huge. That RAM takes away from other things, such as the number of background processes that can be kept running, potentially slowing down things like app switching.

• Because of the overhead of OpenGL, one may very well not want to use it for drawing. For example some of the work we are doing to make Android 4.0 run well on the Nexus S has involved turning off hardware accelerated drawing in parts of the UI so we don’t lose 8MB of RAM in the system process, another 8MB in the phone process, another 8MB in the system UI process, etc. Trust me, you won’t notice -- there is just no benefit on that device in using OpenGL to draw something like the status bar, even with fancy animations going on in there.

• Hardware accelerated drawing is not a magical silver bullet to butter-smooth UI. There are many different efforts that have been going on towards this, such as improved scheduling of foreground vs. background threads in 1.6, rewriting the input system in 2.3, strict mode, concurrent garbage collection, loaders, etc. If you want to achieve 60fps, you have 20 milliseconds to handle each frame. This is not a lot of time. Just touching the flash storage system in the thread that is running the UI can in some cases introduce a delay that puts you out of that timing window, especially if you are writing to storage.

• A recent example of the kinds of interesting things that impact UI smoothness: we noticed that ICS on Nexus S was actually less smooth when scrolling through lists than it was on Gingerbread. It turned out that the reason for this was due to subtle changes in timing, so that sometimes in ICS as the app was retrieving touch events and drawing the screen, it would go to get the next event slightly before it was ready, causing it to visibly miss a frame while tracking the finger even though it was drawing the screen at a solid 60fps. (Edit: for those who need this made clear, yes of course this particular issue is fixed.)

• When people have historically compared web browser scrolling between Android and iOS, most of the differences they are seeing are not due to hardware accelerated drawing. Originally Android went a different route for its web page rendering and made different compromises: the web page is turned in to a display list, which is continually rendered to the screen, instead of using tiles. This has the benefit that scrolling and zooming never have artifacts of tiles that haven’t yet been drawn. Its downside is that as the graphics on the web page get more complicated to draw the frame rate goes down. As of Android 3.0, the browser now uses tiles, so it can maintain a consistent frame rate as you scroll or zoom, with the negative of having artifacts when newly needed tiles can’t be rendered quickly enough. The tiles themselves are rendered in software, which I believe is the case for iOS as well. (And this tile-based approach could be used prior to 3.0 without hardware accelerated drawing; as mentioned previously, the Nexus S CPU can easily draw the tiles to the window at 60fps.)

• Hardware accleration does not magically make drawing performance problems disappear. There is still a limit to how much the GPU can do. A recent interesting example of this is tablets built with Tegra 2 -- that GPU can touch every pixel of a 1280x800 screen about 2.5 times at 60fps. 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.

• 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.

EDIT:

Wow this has generated a lot more discussion, and I won't be able to address nearly everything that has been raised. But I'll try to expand on things a bit here to better address what I think are some of the more interesting points.

Some have raised points along the lines of Samsung Galaxy S2 phones already having a smoother UI and indicating that they are doing something different vs. the Galaxy Nexus. When comparing individual devices though you really need to look at all of the factors. For example, the S2's screen is 480x800 vs. the Galaxy Nexus at 720x1280. If the Nexus S could already do 60fps for simple UIs on its 480x800, the CPU in the S2's is even better off.

The real important difference between these two screens is just that the Galaxy Nexus has 2.4x as many pixels that need to be drawn as the S2. This means that to achieve the same efficiency at drawing the screen, you need a CPU that can run a single core at 2.4x the speed (and rendering a UI for a single app is essentially not parallelizable, so multiple cores isn't going to save you).

This is where hardware accelerated rendering really becomes important: as the number of pixels goes up, GPUs can generally scale much better to handle them, since they are more specialized at their task. In fact this was the primary incentive for implementing hardware accelerated drawing in Android -- at 720x1280 we are well beyond the point where current ARM CPUs can provide 60fps. (And this is a reason to be careful about making comparisons between the Galaxy Nexus and other devices like the S2 -- if you are running third party apps, there is a good chance today that the app is not enabling hardware acceleration, so your comparison is doing CPU rendering on the Galaxy Nexus which means you almost certainly aren't going to get 60fps out of it, because it needs to hit 2.4x as many pixels as the S2 does.)

To be complete, there is another big advantage that the GPU gives you -- many more drawing effects become feasible. For example, if you are drawing a bitmap in software, you basically can't do anything to it except apply an offset. Just trying to scale it is going to make rendering significantly slower. On a GPU, applying transformations well beyond simple scales is basically free. This is why in the new default Holo themes in Android we have background images -- with hardware accelerated drawing, we can afford to draw (and scale) them. In fact, if the hardware path is not enabled by the app, these background images will be turned off.
2994
1837
Kah Ping Tan's profile photoAmo Aras's profile photoTerrence Lui's profile photoMatthias Klan's profile photo
318 comments
 
seems it could actually be worse if the GPU is very slow
 
+Josh Kimble - Indeed, it's interesting that on some devices (e.g. Nexus S) the memory bus is so fast that the CPU can also complete certain specific graphics operations very quickly.
 
Great post, and an interesting point about the memory overhead per-process. Is this just in the powervr driver, and is it something that could be fixed in there?
 
Great insight! This is a lot more interesting than what I thought.
I promise I will not bitch about the UI smoothness (I never did anyway), unless someone done it terribly wrong.
 
Wow. That was really insightful and interesting. Thank you for posting that.
 
How about touch to display draw latency? It seems a tiny bit slower than iOS.
 
Thanks! Can you also explain how the audio system works, and how/if we can improve the latency in our applications?
 
I love my Nexus S more now. :), great post. Looking forward for more infos like this :p
 
Hi +Dianne Hackborn i just got a Galaxy Nexus yesterday and started porting my honeycomb app to ICS. I am noticing really slow and stuttering listview performance where i had no problems on Xoom or the Galaxy Tab.
Is there anything specific that we should take into account when writing listviews on ICS compared to prior versions? I use the ViewHolder pattern in all of my lists and usually they run butter smooth, but this one doesn't on the nexus, Could it be that i use too much alpha channels in my list item drawables?
 
Interesting but I did not get a conclusion..!! What do u think? Can we ever get some smooth animations on Android without stutter?
 
Great post Dianne!
One question: Does one need 60fps to achieve smoothness?
Would 50 or even 40fps make visibly poorer transitions?

And lastly frame budget with 60fps is 16.6666ms not 20ms
 
Excellent info Dianne! Many thanks. This level of info is very helpful.
 
Good post ... I always thought Android 2.2 & earlier hardly used OpenGL for normal UI rendering as specifications for GPU was not strongly recommended.
 
And from touchWiz 4.0, hardware rendering for home screen has started on samsung phone, thats its smooth now
Previously it was laggy...
 
+Daniel Drozdzewski 50 and 40 fps would look bad on a 60 Hz display, because the display would need to show frames unevenly.

Actually 30 fps would be better than 40 or 50 fps for 60 Hz displays because then you could show every frame twice in a second, so there wouldn't be any jitter. In some cases 30 fps should look smooth, but it's actually more than just the look. The UI would feel sluggish or unresponsive. Going 40 or 50 fps might help the unresponsiveness, but it would add awful jitter to the display. You can best notice this jitter when watching something moving at a constant speed across the display (eg. movie credits) on a display, whose refresh rate isn't the same as the frame rate of the video (so almost every video on the internet on almost every stock flat screen). Be warned: after you see the jitter on the credits, you'll start seeing it in every little movement and it'll eat into your movie enjoyment... :)

Anyway, as a rule of thumb you should always try to avoid lesser framerates than the refresh rate of the display, but if you have to go lower, then go half (or if you for some reason really need to, 1/4th) the refresh rate. The same thing goes for going over the display's refresh rate, if you don't keep the frame rate to a multiple of the refresh rate, you'll again introduce jittering on movement on the screen and that's not nice.
 
Dianne, the resolution is off. We have 1280 horizontal, not 1024. Great blog post, thanks a lot!
 
Leave it to +Dianne Hackborn to drop knowledge on such a scale!
 
This is a great post, I wish 99% users would read and understand it. But unluckily they just want their hardware acceleration turned on and the magic powers of it doing everything fly.

On a more technical note, I've noticed how expensive canvas operations (save layer, porterduff filters, etc) run about 2-4 times faster in software layers than hardware layers, and noticed how great hardware layers perform when using drawing caches.

The bad part is: for a developer, usually there's no easy way of changing the rendering pipeline while maintaining backwards compatibility. So I end up still doing almost everything on a canvas and loosing the benefits of the hardware acceleration for new devices: (
 
But still one question is not really answered, why does almost everybody say that on lesser hardware iOS and als Windows Phone is much more fluent then Android?

I agree on my SGS2 which has powerful hardware i don't have any complaints but still why does Android need that much?
 
Really informative post, there aren't many articles on the web discussing this side of Android.
 
+kunal verma There is in fact background agents allowed, as well as copy/paste in WP7.5. Granted, "true" multi-tasking and "true" background applications are not available, the system as is currently implemented allows for the majority of cases.
 
Very interesting post. Something I've always wondered is why graphical/UI performance on Android devices with Adreno GPUs always seem to underperform compared to those that use another type (e.g. PowerVR, Mali).

This is purely based on my experience with a variety of HTC, LG, Samsung, Motorola, and Huawei devices (I've found it difficult to quantify "UI sluggishness").

Am I drawing incorrect conclusions from correlations here, +Dianne Hackborn, or are there differences in the hardware, or the way Android uses the hardware, that do actually cause this?
 
Wow, most awesome post on Plus I've read this month (if not ever). Think that most of us would be really glad, if that kind of insights would continue.
 
So that means that ICS has way better graphical capabilities than Gingerbread?
 
while it's nice to know what's going under the hood, and i can be empathized with the challenges mentioned above, the fact is that apple is doing a much better job when it comes to graphic performance. like much much much better. until google can fix this, android development is quite a frustrating experience...
 
Interesting, but the question about why animations are nowhere as smooth as “the competition” remains open.
 
so that is why samsung phones will always be faster/smoother than HTC phones because they have a more capable GPU? haha, I hope I am understanding your post correctly.
 
windows phone will rule one day sooon......................
 
Thx for the explanantion. Can't wait to see how this translate to real life usage on the NS. Been running an AOSP build for the pass week and performance is OK but not as fast as GB was. Obviously I'm sure that with the right drivers and kernel the NS should run a lot smoother. Keep up the good work.
 
Agreed - interesting tech info, but doesn't seem to address fluidness. After reading this, it feels more like everything would need to be scrapped and rebuilt from the ground up with new thinking to achieve the fluidity of competing platforms.

This feels very much like late 90's Swing discussions, where people would say "Java apps look like shit", and Java apologists would argue about how fundamentally great Java/Swing actually is, but every single app developer was "doing it wrong", because they didn't understand every single possible piece of code under the hood and how they all fit together (instead of just making all those pieces work together well by default). By the time hardware advanced and Java had progressed so that the combination was pretty usable and smooth on modern hardware, the world had moved on from Java desktop apps.

And now someone will tell me I'm 100% wrong, but that's still what it feels like. :)
 
Thanks for the info, and some of the different issues faced with different versions, :)
 
Thanks for the post.

What is the status of hardware acceleration for HTML5 canvas? iOS5 had a major step forward in this regard. What are the plans for Android?
Tinus U.
+
9
3
4
3
 
+Toan Nguyen +Michael Kimsal If you want to have the same experience like iOS, you need to match it with Android. For example:

- Remove all your widgets, all of them
- Don't use animated wallpaper
- Turn off all background services which are not from default Android
- Choose Android phone that does not have external sd card
- Do not install/use Adobe Flash
- Etc.

For sure, you will get the same experience, less graphical intensive operations, etc. etc.

But, what's the point? What's the point of using Android phone without all of those advantages compare to iOS?
 
I learned to appreciate Android more now. Android is just so advanced that the other platforms can't keep up with what it can do.
 
+Dianne Hackborn Great post, I'm always a sucker for these details. But there's one important aspect you didn't mention: battery usage. Even when the GPU and CPU are able to do the same task "well enough" (i.e. even if the CPU is slower it may not be important because it's fast enough to sustain the required FPS), the GPU will usually do the job wasting much less energy, which in mobile devices is a big plus. Could you comment on that, e.g. have you benchmarked power efficiency of Android in each mode of rendering (in same version of Android and apps)?
 
I'd also like to hear more about HTML5 Canvas performance on Android. In my own testing, HTML5 games are much slower on Android 3.0 vs. iOS 2.
 
+Dianne Hackborn Also, very curious about the 8Mb per-process overhead of GL, that seems a bit excessive considering that the code will be shared among processes and things like pixel buffers are necessary with software rendering as well... (n00b question, never programmed raw OpenGL APIs)
 
Now I know close to nothing about this. But does the fluidity of ios and WP7 have to do with the fact that they are code written from the bottom up, instead of android which is built on top of Java?
 
I would be interested in how Flash is implemented into Android. I don't think Flash is hardware accelerated on Android, so how does it display Flash objects fluidly? (Assuming it is fluid in the first place, it is on my Nexus S)
 
+Naval Gilles, count back about 35-40 comments then read from there... a Johan Compagner asked a similar question and responses followed.
 
+Sean McGuire the responses were not very satisfying. The closed model has and will always have huge advantages in graphics speed. Compare the performance on an Xbox with a 99% identical PC to demonstrate the difference. Coding a graphic layer which addresses a fixed hardware accelerator is simply the fastest way to achieve things so Apple will always have the advantage there.
It´s not the BEST way as it closes off rapid hardware development. The competition for graphic chips for mobile and tablets has just started and you can expect rapid progress from now on. Android will be much better equipped to use new stuff as it´s hw agnostic.
Microsoft is the big question mark with WM7. It´s very fast but still tied to one chipset but M´soft will support other chips in the near future. We´ll have to wait to see if they can keep the fast GUI.
 
Nice article - incidentally, +Zach Pfeffer linked to a tidy little patch that forces sw rendering. It's particularly useful when porting to a new device, or just to get up & hacking when PVR is misbehaving. E.g. the proprietary pvr binaries & driver in +Koushik Dutta 's master kernel for the Nexus S don't play well together.

Soooo... any plans to make an official ICS release for the Nexus S :)
 
One thing you didn't mention is CSS animation in the browser. What's the story behind that? Because the performance is abysmal.
 
+Dianne Hackborn can you comment on battery usage (CPU vs GPU and etc.)? I undestand this may vary greatly between devices (or you may even argue that the screen consumes way more battery than either) but it'd be good to get the big picture.
 
+Matthew Gifford It's not just CSS transitions. Android browser has a slow 2d canvas context. No WebGL, websockets, webworkers, webaudio context, etc. As someone that's developing html5 games, its pretty frustrating at the moment.
 
+Lars Bjerregaard - I'm not sure if any of the existing benchmark suite specifically measure the speed of software CPU rendering into NDK-style graphics buffers. I spent a bit of time earlier this year playing with those APIs on Nexus S, and the raw speed of that CPU for old-school graphics rendering blew my mind, even when running barely optimized portable C code.
 
The problem is that hardware accelerating multiple separate components (like the one in the link from this article) merely served to accelerate the very uncommon case of the home screen. To applications this did not matter. They did not get the benefit of hardware composition, and as far as they were concerned, everything was rendered and re-composed in software.

That is why iPhone's always felt faster. Every UIView in an iPhone was backed up by a Core Animation Layer (CALayer), which was in turn backed up by the GPU.

The iPhone went one step further: CoreAnimation runs the animations on a separate thread, independent of what the user or the application might be doing. As long as you are not blocking the UI by trying to pump events, CoreAnimation will be happy to animate all of the CALayers with their scheduled animations.

This is what gives the iPhone that extra level of smoothness. Android is on the right path, but just because it was able to use the GPU on the fringe case of the home screen, does not mean that apps automatically benefited from it, and this is why every developer claimed as far as they were concerned that Android did not give them GPU composition. They always get it on iOS, they will only get it when the world moves to ICS.
 
Thanks +Miguel de Icaza for the clarification about iOS rendering pipeline for non iOS devs like me.
It finally makes sense to me...
 
So, does this mean that ICS wont lag like every android pre ics? my honeycomb tablet does probably an average of 15 fps. So I just use it for kindle. My Desire HD is a tad better, but still annoyingly laggy. But how hard is it to get iphone 1 lagless interface? No more android for me.
 
+Matthew Addison I'm showing ignorance here - which galaxy nexus? Is there more than one? My brother had - I think - a Nexus S(?) from Google. I used it in Dec 2010 - not sure what version of Android that was (whatever was most recent at that time). It was nowhere near as smooth as my iPhone 3GS at that time. Perhaps you're now running ICS and it's all better now?

Much of this tends to be "in the eye of the beholder", but when I do side by side comparisons at the store between Android tablets and an iPad2 there's no real competition yet. I guess that will change in the next year or so? It's hard to take people's testimony without verification, because I had people last year telling me the Nexus' animation was "just as fluid" as iPhone4, but it just wasn't. Everything those fanboys say now comes under suspicion, and I have to view for myself in person now to judge.

I say this writing from a macbook and now owning an iPhone 4S, but someone who wants to see better competition. Had there been Palm Pre phones that ran on GSM 2 years ago, I'd have gotten one (liked the interface experience). I also liked my quick tests with WP7 handsets, but there's not yet enough to have me leave the iOS camp for daily usage yet.
 
+Tor Ivan Boine my dhd , running cm 7.2 and adwex, has almost no UI lag, other than sometimes jurking off while swiching among lists!
ofc if i'm installing apps or doing huge syncs, everything is slow(er), but other than that, it's fine
I love how i can the Fly In effect on ADW Ex and have it fell smooth!

now i only need to make +Ander Webbs put into game what he learned here, and make large images scroll better in the background... right now, it jumps pixels after i've let go the screen lol
hence why i usually use a single static image that doesnt scroll
 
I just wanna use. I'm tired of tweaking. Scrolling down this post made the phone to lag several times of one second each time. My dual core 1ghz tablet is even worse. I won't even mention my late htc hero. Now that was a real lagdroid
 
Overall performance on the GN is very good, even the G+ app runs pretty smooth, most of the time. I noticed some occasions tough, where the animation is choppy every. single. time. Examples include the gallery app, that never feels really smooth and the animation when I am not on the main homescreen and hit the home button. Scrolling through homescreens is generally very smooth, but this animation is not. Clearly not optimized enough. Maybe the animation is executed a bit too fast...
 
+Max Huijgen, you are right, the responses are a bit lackluster. But, they do highlight some of the issues at hand in bottom line performance. For this, I recommended that Naval read them - in case that he had not - since they could offer some pieces to the puzzle. Your answer definitely does more to answer his question directly but fails to capture some of the other factors that can impact performance. My succinct answer definitely left a lot to be desired in explaining my intentions, opps.

Additionally, I am not sure I follow, or agree, that a closed system is necessarily a negative for hardware innovation. Even with Apple's highly closed system they still go out and test multiple hardware configurations for their products to deliver the best deal. Sure, only one tends to come out winner for the component but that did not negate the lead-up brawl for choice. (Ars Technica did a short article on Apple's dilemma between AMD and Intel for new MacBook Airs.)
Kun Li
 
+Daniel Rose The Gallery is running very smooth on my side. There is no single choppy animation.
 
It seems to me that the Android development team has to fight a lot to keep decent performance, simply because everything is built on top of Java. In addition, the choices that were made regarding windows and views drawing in the framework are often infortunate, and lead to poor performance results, regardless of whether hardware acceleration is in effect.

How could it seem wise to let the UI thread handle animations? How could seem wise to require a REDRAW of a view just to change the opacity (that is, until OS 3.0)? How did it ever seem wise that a view could not have subviews, that you require a subclass of a different view just to add subviews, and that when you write your own classes you need to duplicate code when some of your widgets extend View and others ViewGroup? How could it seem a good idea to let lists start forwarding touches to list elements while trying to detect a fling, instead of buffering them until it decides the tap is not a fling? Why is it so hard for a view to find out what its coordinates on screen are? I could go on and on.

A lot of the backend frameworks in Android are very well thought out, the Intents and Services mechanism are fantastic. But I find that a good portion of the UI framework is poorly designed and impose unnecessary contorsions to developers to reach their goals. It's not far from being a good framework, but the devil is in the details.
 
+Florent Pillet Yeah, I really hope there's going to be some changes from now on. The main focus should be on performance and optimization.
 
In conclusion you could say that the demand for hardware accelerated as such is indeed overrated and far too simplified so +Dianne Hackborn has a valid point.
However in dwelling on it the main concern of the relatively high computing power (let it be CPU or GPU) to get good graphics performance in Android apps is not answered by her lengthy post.
In reality nobody really cares about HW acceleration as it´s a hollow word anyway. What HW? People inferred it had to be a graphic processor but 99% of the people would be hard pressed to name even one.
The Soc´s like Tegra2/3 etc are sometimes known, but which GPU is bundled in the package is hardly discussed. It´s also of no importance to start doing so.
There are loads of graphics operations which are more costly to do in hw than in software especially if your case deviates from the standard model.
From a external developers perspective the graphics layer is an abstract like it is for the public. It´s only really interesting for phone manufacturers, SoC developers, low level driver writers at Google as well as at the suppliers level. Oh and for a few geeks like me who just like to know these things.
 
just like a few have noted here..it's an interesting post...but it doesn't address the fact that iOS 1.0 and WebOS 1.0 pretty much nailed fluid animation and scrolling but Android apparently is struggling still (heck...i gotta admit even Windows Mobile 7 does better)...even with dual-core CPUs and advancements in graphics chip hardware.
 
I love these factual and insightful posts, Dianne. It helps me to digest what is truly happening under the bonnet of Android, so to speak. We need more of these!
 
Oh, what a posts :-)
+Osvaldo Doederlein question is good. Actually, if android 4 really need 8 mb per opengl app instance, there is something rotten in its graphics pipeline system.
+Miguel de Icaza are you that de Icaza? Man who made Silverlight working on linux singlehanded? Thanks for that ios pipelining insight, makes much more sense how Apple is doing this imho.
 
ZOMG.. I read/talk geek every day, but this article is full of things I didn't know(or admittedly understand)..
Oh, and +Dianne Hackborn, my favorite part is definitely "Hardware accelerated drawing is not all full of win." This article is educational and will hopefully keep people from jumping on the bandwagon of thinking everything is always win.
 
+Sean Lumly MS will open up to other chipsets they have said. They provided their own low level drivers for the Snapdragon S2 series which uses the Ardeno 205 GPU. A formidable performer so not a bad choice and Microsoft did an excellent job in optimizing.
However having said that Nokia already announced that they will use the ST-Ericsson NovaThor U8500, a ARM9 device with a Mali 400 GPU in future Windows phones.
 
It's all very interesting, but I don't think all of this gets Android off the hook at all. So the problem is not hardware rendering, it's a choice of drawing strategies that doesn't always perform smoothly. To me, it ends up being one and the same. The layman doesn't know (or care) about this stuff, they just see that iOS is smooth and Android isn't. I'm looking forward to see if ICS got any better in this department.
 
Sure +Sean Lumly but it shows that at the moment only Apple has a fixed GPU (not completely as they upgraded it when they went to what they call their A5 chip). But the thing is people don´t know. Not even developers know that the Adreno 220 is faster than the Mali-400 (the GPU in the Galaxy SII) and how many people even know that Apple uses a GPU, let alone that they know which one.
(okay, currently it´s the PowerVR SGX 543MP2 but developer for IOS or Android would probably not have known it)
So my point stays that the actual hw or even the fact if its rendered in software or on hw is relevant for developers, let alone for customers.
 
+Romain Guy Any idea why swiping leads to smooth transition effects on the homescreen, whereas hitting the home button does not?
+Kun Li That's interesting. Don't know why the gallery app misbehaves for me...

(Regarding the first point: Apple would just disable the function if they encountered anything like that. They prioritize smoothness over features and even over good looks as seen with the browser rendering and the visible tiles. There is definitely some point to this, though.)
 
The question does Apple slows it´s own innovation by fixing a range of products on one range of GPU´s is yes imho. The reverse question has Android an advantage by being agnostic is ´theoretically yes´. If manufacurers would write perfectly optimized silicon drivers and this could be smoothly integrated in the Android graphics core, then yes.
At the moment I think Android is far from reaching the true capabilities of the underlying hardware making the theoretical advantage a mute point. Still brute force always goes a long way to solving problems :)
 
Sounds like more excuses for uninspired and subpar software rather than an actual explanation. Nobody cares how it is done. It is a tad embarrassing to look at a 2011 Android phone that can't draw a list as smoothly as the 2007 iPhone. Not a single Android tablet can even come close to the responsiveness of the iPad, even with much better hardware.
 
From comments in hacker news :
pmjordan 4 hours ago | link From the article: There is still a limit to how much the GPU can do. A recent interesting example of this is tablets built with Tegra 2 -- that GPU can touch every pixel of a 1024x800 screen about 2.5 times at 60fps. 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. I find this bizarre. Are all of these drawing operations using alpha blending (using translucency)? If so: is that strictly necessary for the entire area of all of them? If they aren't using blending, why on earth do they have so much overdraw? The GPU could reduce that to touching each pixel exactly once by using the Z buffer and drawing in front-to-back order.


demallien 3 hours ago | link Indeed. I wrote the graphics motor for a set top. I'd last year, and that is one of the many optimisations the weak hardware required to make UI animations run smoothly. It's hard to believe that Android doesn't do this.
 
+Romain Guy It would be great if you could create a blog post which clarifies how HTML5 content could be optimized for Android. The type of layouts which work best, CSS animations, etc...Some developers heavily invest in HTML5 for building the UI of their apps and up to now, those app have been feeling a lot smoother on iOS than Android. More and more developers are going to follow that path because Mango is also very good at HTML5 processing.
 
Great post Dianne,
This is yet more proof that nvidia made a mistake removing NEON from Tegra 2. Sure, they argue 'time to market' was the reason, but then look at Apple with the vastly superior A5 only a little bit later.
Oh, and the Galaxy Nexus would have been better off with Exynos, or Tegra 3
 
+Romain Guy Thanks. Android 4.0 bringing a lot of improvements in HTML rendering is a great great news. Looking forward to trying them out!
 
Interesting to know that the performance is starting to rest on the bus overheads. Just like my quad core desktop :).
 
After reading this I am looking at my Xperia X10 with pity..
 
+Miguel de Icaza - Actually, on Android pretty much every application benefits from the hardware accelerated compositing of multiple separate components - both the GPU acceleration that has always been there, and the newer "overlay" acceleration in Honeycomb and ICS that allows the GPU to be bypassed. The reason is that things like the status bar and the soft button bar added in Honeycomb count as "separate components," so as long as one of those is visible (which is pretty much always) there's some compositing work that needs to be done. We often use the Home screen as a more extreme example of compositing, but it's by no means the only example.
 
+Romain Guy +Roman Nurik Rendering slowness in HTML5 canvas the biggest problem with HTML5 games for android. Good to hear that there may be performance improvements. Any word on the other APIs? WebGL specifically, but Websockets, Webworkers, WebAudio would also be very helpful. The disparity between the amazing things we can do in Chrome vs. Android's browser really feels like the Elephant in the room. And I haven't heard anyone comment on it.
 
+Romain Guy yeah, now I read it again I find it poorly explained.
I was trying to explain this point:

I haven't found an easy way of using the new (3.x) view property system while maintaining backwards compatibility (real translations, rotations and scaling), so end up manually drawing stuff on a canvas.
But a few operations are slower (ex, create a really simple realtime reflection by drawing a View twice with a porterduff DST_OUT gradient over it) or just not supported on hardware accelerated canvases (clips, maskfilters,shadow layers...) so i need to start doing dirty tricks like "kind of" double buffering drawing everything to a backed bitmap and then to the View canvas (and this can be tricky cause of on hardware layers it may end up drawing unexpected things), mixing hardware and software layers, etc.

Hope this makes my previous post a bit clearer.
 
So this mean that my Nexus S with ICS will run smoother than with Gingerbread? This it what the end user (myself) is interested in. Only the final results are important. All the other things are not
 
Wow thank for this insight. Very much appreciated!
 
Thank you very much for your insight! Well, how does iOS that stuff, that would be amazing to know!
 
+Hugo Castro your point is a good one. The need to redraw stays higher as your Zbuffer invalidates more often than you wish. The one huge advantage of the PowerVR architecture is that their tile based approach to it. It didn´t get the success it should have had on the desktop market but they are back and pretty strong. That´s one of the reasons the Apples perform so well in some higher level OpenGL tests like Egypt.
 
"Full" hardware accelerated drawing within a window was added in Android 3.0. The implementation in Android 4.0 is not any more full than in 3.0."

Doesn't this contradict +Romain Guy and +Chet Haase 's Google I/O talk? They went through a list of what wasn't targetted in the pipeline yet, but would be in the future (some of which were targetted for ICS). Even if none of these additional targets made the 4.0 release, they also mentioned bugs which would be fixed in ICS. I'd still call a less buggy/more optimized pipeline a "more full" implementation.
 
thank you for this interesting article :)
 
Games are where the future performance will be measured +Romain Guy ICS and 2012 hw basically take care of the UI.
I know the mess of deferred rendering but the PowerVR has the upper hand and that will be the next battlefield for mobile and especially tablet gaming.
 
+Romain Guy So we finally have the answer : it's because you have to deal with choices made years ago. I'm definitely supportive but I think it's going to take a lot of time.

 
Wow, either I'm reading this wrong or Android has an extremely stupid rendering design. I do professional embedded GL graphics (and some Qt, formerly RedCineX) so I'm not up to date with the Android framework yet:

* Why isn't drawing a client-server model where all draw commands are funneled to a unified multi-threaded draw server? That way, each app doesn't need a 8MB chunk of driver memory (which is stupid in itself already especially on embedded, Windows Mobile, Qt on Windows Mobile, etc). Only full-screen apps should have direct rendering to the framebuffer. You're already suffering from draw consistency, resource contention by allowing each app to direct render. C-S would separate touch event contention from drawing contention that each Android app suffers from and why iOS has smoother UI.
* An app shouldn't have to be aware it has to be multi-threaded (with its own draw thread) for smooth UI. That's the framework's job. It's truly appalling right how much UI-events v graphics-draw contention is in Android right now.
* Why aren't you using a multi-process scene-graph (each app is a item, and then each item has multiple sub-graphs per app) so you can not only retain what needs to be drawn per global animation updates, but you can instantly and easily cull unnecessary updates per app. Putting each app into an overlay isn't the best way to go without this culling.
* Why aren't you using "dirty-regions" as another way to cull necessary updates (I assume this is what tiles are)? You should be since its a standard technique that dates back to QuickDraw and QuickDraw II, besides MS's windows API.
* With the pixel-overdraw bandwidth issue, you can easily first cull through the scene-graph, then the per-app dirty-regions (or stencil buffer*), and then use the hardware-accelerated *depthbuffer to eliminate more overdraw, and draw front-to-back. This is just simplified because there's more modern GL tricks for culling. So, you shouldn't have to touch each displayed pixel more than once.
* Are you using pixelshaders at all to accelerate standard widgets such as buttons, etc? There's no reason to have large simplified buttons that can't be replicated by instanced models with pixel-shaders in a scene-graph.

Maybe you should switch to the Unreal Engine for drawing instead, or some other modern game engine. These are all solved issues. You have hardware that's generations more performant than the old game systems, but you have a software engine that's generations behind. That means ICS probably still has no hardware acceleration.

A 30fps engine that never dropped a frame is always faster than a 60fps one that does.
 
+Romain Guy Understood, though I still think that particular phrasing has the unintended consequence of being emotionally read by many people as "ICS will perform exactly the same as Honeycomb", which doesn't really do it justice.
 
Thank you Dianne for taking the time to explain the challenges. I really enjoy reading pieces you write like this. I'm still curious why iOS devices are typically much smoother than Android. I hope over time this will change, as Android develops, as well as the hardware.
 
+Roman Nurik Whenever I read this kind of stuff by the Android team it tends to feel wrong. I'm not accusing you guys of doing anything devious, but your communication strategy could use some help. This post feels like somebody making excuses (even if it isn't meant that way, but that's the trickery of communicating in public) for a frustrating situation that hasn't been solved in a long time. It also makes me think that somehow the right priorities are not being set, seems odd that you now have Face Unlock but you still don't have a good compositing engine that takes care of drawing the UI and keep it smooth as in iOS. I understand sometimes you need the feature that makes for a good demo, but in that team somebody should just put his foot down and say "we need to fix x, y and z before we add anything else".

+Joseph Lee Just wow. Your comment was one of the most interesting things I've read all week, thanks.
 
+Joseph Lee Suggesting a 3D game engine as basis for a lightweight mobile operating system that needs hardware accelerated 2D graphics is downright silly. 2D is a different game and you should better know if you want to give advice to the Android developers. Also, your conclusion is silly as well. Hardware acceleration = tasks performed via GPU and not in software via CPU.
 
As an engineer, I truly appreciate the technical details. As a user, I couldn't care less about the technical details.

The Android home screen is too fancy, and requires advanced hardware to run smoothly. Nexus One and Windows Phone 7 runs on the about the same hardware (800x480 display, QCOM single core Snapdragon). Windows Phone 7 feels more much smoothly. It is true Android has more features, but it should have those features if hardware can not handle it. Remember the 3D effect of "All Apps" view. Once you have background processes running, the performance start to suck. ICS also has too much animation that hardware can barely support well.

Another fundamental difference is animation. On iPhone, you can scroll any browser page smoothly while it is loading, even you may likely just scroll a blank page. On Android, the scrolling simply stalls for seconds. The same for YouTube home view on Xoom. To make the UI smoothly, you don't need to render every frame, you just need to animate every frame. Remember high quality movies only render at 24fps. Android needs a high quality animation framework like iPhone/Windows Phone.
Tim Box
+
1
2
1
 
Thanks for that. I love Android but its got were it is because its open and every manufacture can build with it, not because there a widgets etc. Its a shame the user experience that people notice is not held as the priority.
I wonder what speed of CPU you need to get to before its will no longer be an issue.
 
+Michael Wang "On iPhone, you can scroll any browser page smoothly while it is loading, even you may likely just scroll a blank page." They already changed their approach in ICS. Now you get bitmaps instead of the fully rendered webpage while scrolling, as far as I understand. Also mentioned in the original post.
 
I read it this way: ICS isn't as awesome as every wants it to be. Developers will still need to do work to make their apps run well.
 
Sweeeet, now if only "you guys" would hire someone to... I don't know, Document these sorts of things, it wouldn't have to be a rant every now and then ;)
Just sayin...
 
Jamie, it is a fringe use. You had to point out to a feature I did not even care. This overlay might be accelerated and yet it did nothing for developers trying to get anything remotely passable for rendering other apps.

Until Android fixes these fundamental problems in the way iOS or WPF or some game engines handle it, it will continue to feel like a dog.

On a separate note, this post comments scrolls like warm butter on Google+ on a 3GS and like God's own baby butter on the 4s
 
The progress of the Android team is nothing short of amazing. You just have I remember that the UI toolkit for Android was designed to be a "better blackberry". It fell short of imagining what the future was going to be like

You can see this transpire on the rendering system, but more painfully in the resource system and the butchered Linux userspace.
 
Informative post. Are there any plans to incorporate the NEON-optimized graphics libraries into Android? The Linaro project has ported libjpeg-turbo to the Android build system, for example.
 
I'm also very curious to hear more about NEON vs. GPU based rendering in Android. Obviously the GPU can crunch a much larger number of pixels, but NEON is backed up by a more sophisticated ARM front end. How do the two end up comparing for rendering UIs?
 
...So, just wondering, did you fix the timing issue on the Nexus S, then? Or is that enough of a bug to devote time to? I mean, "Slightly less smooth scrolling on app screen on Nexus S with Ice Cream Sandwich than with Gingerbread." isn't much of a bug, or a problem to anyone less obsessed than Matias Duarte. Then again, I imagine you guys are full of people as obsessed as Matias. Good work doesn't get done without dedication, after all.
Anyway, great post. Always nice to know someone cares enough to keep in touch with the masses.
 
+Sam Hatoum It's the difference in philosophy. Apple doesn't allow true multitasking because it can hurt performance, Google has no choice but to allow it with its open model. Apple has only so much effects as the iPhone can handle in every situation. Google has nice animated backgrounds /moving wallpapers and Widgets and fancy transition effects that all eat away the performance. Also, some problems might stem from Java (+ the Android browser has only recently (ICS) started to become good. Apples Safari seems to have faster Javascript support in real world scenarios).
 
A friend of mine told me it was because IOS had no garbage collector. It makes you device faster, but makes it vulnerable to memory leaks due to programmation errors.
 
wow 8mb of fkn ram, when a device has 512, 1gb or more who gives an ish?
Andy Turfer
+
29
30
29
 
It's posts like this that really annoy me. Why? Because there is a real issue with scrolling, fluidity and lag on Android devices. While this post may offer the technical reasons (justifications?) for the problem, it doesn't exactly acknowledge the problem or offer a solution.

Samsung have worked miracles with Android and have almost cracked it on the S2, but the 'fluidity' and smoothness still isn't consistent throughout (for example, scrolling through a long list of SMS messages from a contact, or contacts themselves). This has a negative impact on the end-user experience.

As the owner of a Galaxy S2, Galaxy Nexus and iPhone 4, I can testify to the unpleasantness of the Galaxy Nexus. A mere 27 messages in an SMS thread and it stutters (is choppy) when scrolling. Many web pages stutter when scrolling. It feels like a "half-baked" product (I don't know how else to describe it). Third-party apps, like Engadget - buttery smooth on the Galaxy S2, laggy and choppy on the Galaxy Nexus.

Apple knows the importance of UI fluidity and end-user experience, as does Microsoft. But for some reason, Google would rather try to convince people the problem doesn't really exist, isn't important, or will be resolved when CPUs become faster and have more cores (see Google IO: Google I/O 2011: Accelerated Android Rendering - fast forward to about 2:10).

Google changed the status of Android Issue 6914 (http://code.google.com/p/android/issues/detail?id=6914) to 'released' (post 197), claiming that HW acceleration was added in Android 3.0. Yet scrolling and panning/zooming is as choppy as ever. It is with good reason that 'Android' is synonymous with 'lag' (although 'lag' might be the wrong word, 'choppy' or 'stuttery' may be more appropriate).

I have released a YouTube video to try and demonstrate the problem - Samsung Galaxy S2, Samsung Nexus, iPhone 4s - browser scrolling comparison. Unfortunately, my iPad doesn't seem to record at a high enough frame-rate to do it justice. I can tell you from first hand experience that the 'stuttering', choppy, laggy (whatever you want to call it) scrolling on Android devices has a profound negative impact from a user-experience perspective. It makes Android look and feel like a sub-standard product - like something 'experimental' compared to WP7 and iOS devices (and even MeeGo).

Samsung has addressed the issue to a certain degree in their Galaxy S and S2 handsets (for example, the browsing experience is fantastic on these devices). Why can't the 'Pure Android' experience be the same?
 
I'm having a hard time understanding the posts now :) so in the end will my nexus S run a lot smoother than GB? I hope the Android team fixes all these problems. I want them to achieve the recognition that they deserve. Focus on UI smoothness instead of adding new features in the next versions.
 
+Miguel de Icaza - Sorry if I wasn't clear. The status and button bars that I was referring to are the system-wide ones where notifications about upcoming appointments or new email show up. The fact that those are always visible regardless of which app is running means that an Android device always needs those windows to be combined with the app's window to construct the final image that shows up on the screen.

The point I was trying to make is that while Dianne's example of the home screen is an extreme case of how accelerating window composition can be beneficial, that acceleration also affects pretty much every single image that gets displayed on the screen of all Android devices. It doesn't directly speed up the creation of the app's window contents, but not having it could sure slow down how long it takes for that window contents to get onto the screen.
 
+some guy it is actually quite a big deal -- a Nexus S has about 350MB available to user space. If you lose 8MB for 3 system processes, and for the home app, and the current app, that is 40MB right there. At this point we haven't even gotten to the overhead of having to load bitmaps into textures and such. The web browser can easily want to use 200MB to handle complex pages, now we are at 240MB, and we are getting well into the area where you notice coming out of the browser that basically the rest of the world had to get tossed out of RAM.
 
I think that reddit thing is nonsense. Using events/queues/interrupts/whatever doesn't change the fact that sooner or later your "main thread" as he calls it has to stop what its doing and respond to input. The high level construct you use to represent that process may hide the details from the developer, but it doesn't change the underlying operation.
 
+Dianne Hackborn I'd like to thank you for your explanation from the bottom of my heart. For the past 5 months, I've been trying to understand why apps on my Nexus S (usually) ran better than those on my Galaxy Tab 10.1 . I've watched and rewatched +Chet Haase & +Romain Guy 's Google IO 2011 videos, read & reread +Anand Shimpi & +Brian Klug 's writeup of the difference ways GPUs render content. I have contacted each of these men on their Twitter and Google+ pages multiple times and though they've been helpful, your explanation ( + the information I gleaned from them) has finally brought closure for me in my understanding of this.

That said, I have two questions for you :

How much RAM does Tegra 3's OpenGL driver use as compared with PowerVR's 8MB?

What calculation can I use moving forward with respect to GPU speed (which I assume is raw fillrate), memory bus bandwidth and screen resolution to at least get a guesstimate of how my future #android devices will behave on the stock UI maintaining 60fps.
 
This is interesting, if you guys want to see what apps should be like in Android, download Juice Defender-battery saver from the market. I swear that it is the smoothest app I've ever used on Android and gives me more questions than answers as to why this can't be done elsewhere across the UI. I don't even use the app anymore I just have it to wish maybe one day my phone could be that smooth...
 
Thanks for the explaination. But the android team should probably spend more time in catching up than writing excuses here.
 
So, basically what Dianne Hackborn is saying is that even with hardware acceleration, the Android team still couldn’t get a completely smooth experience because of the badly designed foundation on top of which they built Android’s UI layer. Interesting to know why it happens, completely misses the point why people demand "HW acceleration"; they demand "smooth", actually and don’t give two flying shits about how it’s implemented or what the technical difficulties are. If iOS, Windows Phone 7 and WebOS could do it in their initial versions, Android taking 4 versions to get anywhere close just looks lame to most people.

But hey, I’m certain all the people who used to get annoyed by the choppy UI will now say "Oooh, yeah, well, hardware acceleration isn’t always a win, anyway." You go, Android Team!
 
I think what I want to know most is what is going to happen to resolve these issues with Android. The UI delta is one area I'm an apologist in and its making me rather frustrated that the OS I'm fundamentally attached to and supposed to "connect" with stutters and jerks. +Romain Guy indicated that to fix this scenario may ultimately require rewriting the framework. Is that true?

I want Android to be the best it can. News like this, while incredibly interesting, is also disheartening. Clearly, the engineers can't be satisfied with performance? This post alone was constructed out of frustration brought on by users who are equally unhappy.
 
+Dianne Hackborn your post makes it sound like the 8MB issue is specific to PVR and maybe a driver issue not hw. Is that true? Can you elaborate on if this applies to other graphics hardware and if it a driver issue on PVR if the driver can be fixed? Thanks.
 
+Justin Shidell You've put it in the right : +Dianne Hackborn 's post explains lost of things but the conclusion is that the UI framework is deeply flawed.

+Romain Guy Does solving the issue ultimately require to rewrite the framework ? What about adding a new framework instead of fixing or replacing the current one ?
 
+Romain Guy I would like to say thank you for posting at all and to everyone else its being improved on and they have to spread the workload and ICS on my Nexus S runs great mostly just hope now that some of Android UI/GUI complaints have been addressed performance and of course more features will be a focus for Android 5.0.

I do feel for developers cause I'm sure there is a lot you would like to do but can't because of current limitations and sure glad I had this talk with +Rich Hyndman before (not as in depth) to understand half of what most of this language getting thrown around
 
This is a fantastic post +Dianne Hackborn. Really keep them coming. Learning about the true way that things were done from the source will help everybody.
 
Very helpful post. Clarified some misconceptions.. Thanks.
 
thanks for sharing this very insightful information :)
 
Thanks for the clarification. Excellent.
But considering all these points we have to admit that Apple did a pretty good job getting iOS to run so smoothly on the Iphone/Ipad, even though those devices are inferior to Android hardware in many cases. Of course Apple engineers only have to program for their own dedicated hardware which is a lot less interesting for us consumers.
 
So whats the answer to.. why ios ui is buttery smooth and androids' not??
 
>> It would be good to get an explanation for why scrolling/panning is so much slower in Android than in iOS
>> So whats the answer to.. why ios ui is buttery smooth and androids' not??

Reason is quite simple. Android is on many devices. Not all devices has good drivers/ support for right OpenGL extensions ...
AFAIK Apple did one thing right at the start -- they made sure that they can scroll texture smoothly ...
On many Android devices you cannot simply upload quickly enough texture to GPU ..

--
One thing I'm surprised is that they plan to abandon Display List. Why ? You should be able to buffer it anyway... And if
you cannot paint it in time, you can still show checkerboard ...(for extreme pages).

Anyway, it must be interesting job :-)
 
Android was built to be a "better blackberry", but after 4 versions, smoothness and fluidity hasnt been prioritized. If I was an engineer working for the android team at Google, I really would stress this issue as a very very high priority.Face unlock got introduced in ICS but they didint care about Android flawed structure.
 
+Ashish Soni Basically the answer is: Google is The New Microsoft. Or, more specific: the Android Team might be made up of great engineers, but great engineers don’t always make for great software architects and even less for great user experience designers. And it’s definitely more fun to work on something like Face Unlock than it is to architect a solid UI rendering layer—especially if you keep thinking that the CPUs will "catch up" sooner or later.
 
"rewriting the input system in 2.3"

Wonder if there's any place I can read more about this, since I've noticed some lag introduced in one of my games after installing the 2.3 update. Haven't been able to track it down yet, but traceview seems to show a seemingly inexplicable lag in touch event handling...
 
Well this just goes to prove my point that Android was broken from the get go and is being fixed now. I'm horrified to learn that my current phone uses its CPU to scroll lists. What a joke. What is this? 1999?
 
thanks for enlighting me with some useful facts
 
great info, could be less defending. after all, the end result is ios is more smooth
 
Does Hackborn make you like the Dragonborn of hackers? O_o
 
Thanks for the fascinating "expose". Very nice.
 
So since the galaxy s 2 has slightly less pixels and a smaller screen, but a slightly better cpu and gpu it would be a better ICS phone then the galaxy nexus ( if it weren't for the touchwizz and bloatwares)?
 
Hi, I'm didn't have time to read through ALL the comments. Hopefully someone else said what I will say now, if not, I am disappointed.

What people mean when they refer to Android not using hardware accelerated graphics is that it does not use optimised graphics acceleration for that specific device. OBVIOUSLY it uses hardware acceleration at least to some point else you would have a graphics system like the phones had 10 years ago.

Optimised graphics acceleration is very hard to achieve when catering for multiple platforms and manufacturers as you can clearly reflect from the article above: the more different frame rates, GPUs, Processors, Ram, Storage, Screen Sizes, Resolutions you have, the more you have to start coding for the "general" solution rather than the perfect solution to each phone's specs. Apple only releases one phone a year (on average) and only support the latest 3 models in their latest Operating system. They therefore only have to consider 3 different performance parameters which they can still optimise individually. This is why iOS is much more "smooth" when scrolling up and down huge lists and using animations and such than some android phones of the same specs or even more powerful phones. Google leaves the finer core optimisation to manufacturers themselves. The best at the moment that I know of is HTC's Sense which enhances the optimisation of animations specifically for some of their devices.

Apart from this, a well written article.
 
+Etienne Levesque Guitard I take it you didn't read the post at all? I mean, how many times did Dianne state that differences in smoothness between (for example) iOS and Android is NOT just due to hardware accelerated rendering?

I'm horrified to learn that people comment just to prove the point that they didn't read this explanatory post - or at least didn't switch their brain on while reading. What is this? 1999? ;-)
 
+Pablo Llopis I read the whole post with passion. Never in my comment did I state hardware acceleration as being the sole reason for smooth animation on iOS. The article simply proves my point that there were stupid engineering decisions when it came to Android's original design.

I'm not claiming GPU is a magic solution, but it's a certainly more capable one if well done. Apple's implementation in iOS is a clear demonstration of this.

It's limited for sure, but when implementing things in the way of a DSP, it's much easier to have low-power GPUs that do just certain things, and very well, hence the ability of modern smartphones to playback HD videos.

Apple did the same for iOS, and obviously you have to use their APIs in a very specific way to achieve the smooth result, and with only one possible compiled non-garbage collected language, but it works, and it does offload CPU resources and has allowed A4 chips to feel as fast as Samsung's dual core Exynos chip in day to day operations.

That's a chapeau to brilliant engineering decisions at Apple, not an uneducated comment on a post you purport I did not read.
 
OK, so it sounds like a new UI toolkit is needed, so has anyone started on this yet? I was all ready to jump on board and become a full time Android developer, but if my app will end up choppy and sluggish and ugly, why should I waste my time?
 
Just some comments on the post of +Andrew Munn linked by +Sean Lumly. Just to clarify. Ui applications have a so called ui thread that runs the event loop. In Android the event loop handles user events and draws screen updates.

This is the main reason the UI will lag when a heavy operation is done in the ui thread. This might be a cause of choppiness.

However when doing animations, As I understand it, Android is also using the ui thread. Core Animation on iOS uses a different thread which animates the prerendered views.

This is probably difficult to fix without breaking backwards compatiblity. And probably there are a bunch of other things people like +Romain Guy can do in order to increase the speed of Android.

Currently Android runs OK on most devices. And it offers a lot of more functionality like Widgets and Background Services which can also eat CPU.

It would be cool if +Romain Guy could give us more insight in how animations and the design of Android affect the percieved chopiness.

B.t.w. to be honest. Android runs fine on my Nexus One without many performance glitches. But on my Xoom One. Android 3.2 is a total nightmare. Just scrolling trough this web page or over the homescreen make my eyes bleed.
 
Diane, are you on drugs? It's late and I'm tired but.... 1000ms (1 second) / 60 fps (frames per second) = 16.666ms, not 20. No wonder you run out of time if you are aiming at 20 when you only have 16. But perhaps you were generalising.

But to be honest, why are we even talking about time in such huge pieces like ms? 1ghz = 1000,000,000 ticks. So to push a pixel to a frame buffer takes what on a tegra2 soc?? 8 T-STATESor 390fps! So you need about 15% of one cpu. The rest of the time you are drawing this frame, but you said its already done? That said, I don't know the exact pipeline or instruction set of xxx soc. But sounds like you aren't doing this in assembly! And surely some socs have some calls to help you easily push memory around.

I find it hard to imagine such a HUGE organisation as Google with it's limitless funding not to write all of the time dependent areas of code in assembly though? Probably too many people in meetings, and not three or 4 semi-smart hacker types architecting this small OS. You would think it's rocket science or something it takes you so long to release a new version only to whinge about it being slow. Funny how the world is full of such narrow sighted people nowadays. I blame OO programming and things like agile.
But hey, your post at least seems a little informative than usual, I guess you cant really say despite the do no evil. Good luck :) and hope it's fixed soon and running like 7-8 times quicker so you can power down the CPU speeds and improve battery life.
 
Great summary and response from +Andrew Munn https://plus.google.com/100838276097451809262/posts/VDkV9XaJRGS. Basically Android continues to brute-force its UI. When it needs 2-4x the hardware to approximate iOS, and still imperfectly, you know it went off into the wrong deep-end.

Considering that Android is at API #14 without permanently fixing this core problem area through so many revisions (framework threaded UI rendering with highest priority), it's easy to project a WinMobile legacy death with this kind of project prioritization. Android needs to cut and fix it now, or it's already too late. But, Google doesn't build platforms, right?
 
Even QUAD Core in the ASUS prime apparently doesn't resolve this lag/stutter issue:


http://www.engadget.com/2011/12/01/asus-eee-pad-transformer-prime-review/

"...we were sorry to still see some occasional stutters and hiccups from time to time, instances where the device would hesitate for just a half-second or so before responding. There are three performance modes that are easily selected between in the pop-up settings menu, but even on its highest we couldn't get it to be a consistently smooth operator. They're the kind of stops and starts we've seen on just about every Android device to date and it's a bit of a shame that even four whopping cores running at 1.3GHz can't do away with them."
 
But after reading this great technical explanation how great stuff is, my HTC still does not work faster and still sucks at graphics performance. Maybe I missed some spell step in the article, lemme read it again...
 
This post and all the replies that I saw from developers show how much Google support sucks. Google needs to wake up and start supporting their OS developers.
 
So the only real downside to full hardware acceleration is that it might use an extra 8megs of ram? Personally looking at my processes, I see countless apps that I barely ever use being loaded into ram. I would be willing to sacrifice one of them for a UI that is not choppy.

IOS seems to have figured this out a log time ago, and its sad that Android is always playing catch up to these kinds of things. There is no reason why my Android phone, with higher specs and more ram, should be running choppy while IOS runs smoothly in almost all conditions on lower end hardware.

As much as I dislike Apple, I do have to admit that they pay attention to details like over all all user experience and put that as a priority. Its sad that its taken till ICS for us to get similar benefits in our Android phones that IOS has had for years now... and even more sad that most of us will need to buy a new device as its unknown if ICS will be ported to our current devices.
 
Way too many comments to go through, but forget it's a lot easier to get stuff like this right when you control the hardware and software in house and it's all proprietary, rather than building an os as open source, from Linux roots, to an imagined minimum spec.. all while trying to coordinate so many different groups. The hard work is done now. Android is a modern, expandable os with flexiblity and a bright future .
 
Oh Its an apple vs android thing lol. Soc gfx like Mali do much more than render 3d btw , along with other arm bits like the Stuff in the cortex a9 etc most are built around they handle hd video, audio, networking, HDMI and a lot more. Multitasking was a design choice and it's easy to get bogged down, but you dont need to run everything you know..
 
An extremely informative and interesting explanation. Though I still don't understand if the problems/solutions were that cut and dry, how has Android gone one so long with laggy interface views with more powerful hardware while iOS is as smooth as mobile OS' go (tied with WP7 in my book)?
Mark S
+
1
2
1
 
Yay, so it's not that you don't use GPU, it's just that your implementation sucks compared to the competition. The whole reason this debate even exists is because it is so bad compared to iOS. Maybe acknowledge that and move on? Figure out how to win. Come up with the equivalent of Core Animation from iOS. 
 
Unfortunately it seems they don't need to. People end up buying more and more Android devices. I think their priority is making sure your apps will work on the new phone you buy.

It's sad though. I would actually opt for a compatibility mode for older apps and a brand new framework.

Out with the old, in with the new.
 
great post i fell in love with my nexus s all over again
 
I would love to get an understanding of which manufacturers put similar effort into these subtle optimizations for their devices in order to ensure the target 60fps is hit, just as Google is doing for 4.0 on the Nexus S.
 
Sounds like Windows vs Mac prior to Windows 7 all over again.

Having to code for only a handful of devices will generally be a lot easier than coding for a multitude of hardware specs. When you factor in the carriers...
 
Another factor to consider with the smoothness of browser scrolling is the scroll speed. Android devices seem to mimic the finger's actual scroll speed and accelerate it depending on the gesture. Whereas iOS devices seem to use "half-speed" scrolling for fast flicks in order to minimize the number of unrendered tiles.
 
Great information about hardware acceleration. Thank you.
 
I really want the information like this. ^ ^
 
I agree with most other people here, Android is version 4.0 now, and with hardware more superior than iShits the coppy UI is UNACCEPTABLE!

All I want to say here is how many Ph.Ds you have Google? How many software engineers you have Google? I believe any people with Com Science or Software Engineer degree know what does refactor means. Maybe what you have to do is more than code refactor, but if I am an end user, I will not care about how you make the UI butter smooth. I see the main reason you not changing your FAILED UI design is because of backward compatibility, I call this BS. Apple experienced PowerPC to Intel change and I don't see why Android can't do it. And if you really want do solve this problem, do it right now before its too late. As a developer I'd like to change my code so my app will have a better UI experience and Google you are scared about lazy developers who are not willing to do so?

If I am the project manager of Android project, I will call all my teams to cut all the shit for a year and at least get the UI smooth as hell. Next year is critical to Android, maybe I cannot change the world, but if Android continuous to be like this, and WP7 is getting better, my next phone will not be an Android phone anymore for sure
 
"Hardware accelerated drawing is not all full of win. For example on the PVR drivers of devices like the Nexus S and Galaxy Nexus, simply starting to use OpenGL in a process eats about 8MB of RAM..."

8MB of Ram? waste?. Sorry! My galaxy S2 have 1GB of ram. I need OpenGL can use more 32MB of ram for best UI. And future we will have 2GB of ram.
Did you see laggy when cpu loading data + cpu loading UI?. Did you see iphone 3G with old date GPU and GPU but UI still smoother than your Nexus S. Do you know everyone love UI smooth like iOS?, no one like UI laggy like android.

I hope android will have full GPU acceleration. Now android have strongest hardware CPU + GPU. Please! full support GPU acceleration.
 
+Etienne Levesque Guitard of course iOS has a better graphics implementation, that is why I used it as an example.

Using the CPU is what is mostly referred to as doing stuff in software, everything else is usually referred to as using hardware acceleration. Your original comment stated that you were horrified that list scrolling was done with the CPU (aka in software), therefore I inferred you were horrified it was not hardware accelerated.
The point of the whole post is to address the fact that the smoothness problem is not due to the lack of hardware acceleration everywhere - including list scrolling - and it is used precisely as an example of where modern phones such as the Nexus S reach 60fps using the CPU without any problems. Hence your first comment looks like you did not pay enough attention.

I agree with most of what you say now that you have clarified, and that Android is now being "fixed" and must try harder to keep up to speed in smoothness. Clearly Android was not designed for smooth UIs everywhere, and Apple got this one right from the beginning.
But I think you mistakenly oversimplified by addessing the CPU-accelerated list scrolling example, where 60fps is purpotedly reached, and smoothness-scrolling issues lie elsewhere.
 
+Dianne Hackborn +Romain Guy Don't want to pay the price of backwards compatibility breaking ? What about paying the price of Android remembered as the "We don't want to bother people with a brave and honorable move. The OS is not great but not too bad" product ?
ham zed
+
1
2
1
 
I am not an Android engineer/developer, but I guess if 2D games like Angry Birds or 3D games like Air Attack HD can run so smoothly on my Nexus S, so could my Android UI. It is the same hardware for all, after all.
 
I would marry you. You are such a perfect girl. :-)
 
+ham zed I'm guessing they run smoothly cause they were implemented with a separate high priority UI thread (as any game should be right?)

You're right, it's the same hardware. It's too bad Android wasn't implemented the right way from the start. Even Windows 7 has a high priority UI process.
 
I want some more, give me more info, please. This helps the society to understand more Android.
Please post more.
 
So, clean and simple: the current UI symptoms will be the same for the near and foreseeable future, with its pros and cons. Good to know, and thank you for the straight talk, +Dianne Hackborn. If only we had had that post before. That's why I don't like PR people and like engineers, developers and the technical staff.
 
Now those arrogant Apple fanboys can bite me - iPhone UI speed is often cited as proof that Apple are just better. I suppose this will be less of an issue with these new dual core phones coming out?
 
I read a lot here and elsewhere about how great Android is and how much better ICS is, etc., but it doesn't matter what Google does regarding development of Android's capabilities when the phone manufacturers don't provide updates for their phones which are capable of running newer iterations of Android. For example, LG is notorious for not providing updates to their phones either in a timely fashion or not at all for phones such as the G2X (LG-P999) and even when they do provide an update, it is staged around the world and usually only for their non-branded phones so that owners of carrier branded phones either get their update too late (after another iteration of Android is released) or not all (such as with the WIND Mobile LG-P999 Optimus 2X). Google has to make it a requirement that no cell phone manufacturer can delay or not provide Android updates within a specific period of time in order to be able to use Android in their cell phones. As well, chip manufacturers such as NVIDIA must provide the source code and programming tools fo the chips they manufacture which are used in phones, tablets, etc., which use Android so that independent developers can fully port "vanilla" Android to any Android operated device immediately after Google releases a new iteration of Android. Doing what I ask for will remove the BS that chip and cell phone manufacturers use to frustrate and abuse developers and consumers. How about it Google? And, don't tell me that I should have bought a Nexus!

I own an LG-P999 which is also known as a T-Mobile G2X which is also sold in Canada as the Optimus 2X which is dentical to the G2x LG-P999 not the Optimus 2X LG-P990 sold everywhere else in the world and it is branded with Google's trademark, Google, on a metal plate on the back and I am still waiting, as are all the other owners of this Google branded LG phone for the promised update from Android 2.2 to Android 2.3 which WIND has stated is in LG's ballpark and, although LG has announced it will provide Android 4 for the LG-P990 (Optimus 2X) but it hasn't stated it will for the LG-P999 (G2X/Canadian LG Optimus 2X available through WIND Mobile.).
 
that's nice and all but many just want a smooth phone experience with the freedom that Android brings. How long until Android can provide that? Never? That's what this post sounds like-- "Android wasn't designed to provide smooth HCI, and we're not going to fix these design mistakes".
 
Sooner or later we'll get a completely overhauled graphics framework. Competition with Apple and Microsoft will ensure that.
 
Great post... Thanks for trying to be clear. Not sure why most of these comments are so harsh simply because you are trying to disseminate correct information. I am by no means an expert, so please, correct me where I'm wrong here.

I think the vast majority of commenters here have probably only used a 2.x version of android on a phone, and device manufacturers have a funny way of advertising features that go unused - even ones as big as not supporting multicore processors (The kernel for Gingerbread is based on 2.6.35, 2.6.36 is the first kernel with multicore support which is present in Honeycomb+). I personally am looking forward to using my device (LG-P999 - g2x) to its full potential whenever the cyanogenmod team can port ICS over to it (However they do this without nVidia/LG's help with the proprietary HAL binaries is beyond me, but more power to them). I'd like to think that if the current owners of a dual core device had the kernel to support actually splitting the UI thread and the worker threads onto separate cores instead of still having to be scheduled on the same core, people wouldn't be such sad pandas.

Since people seem to be a bit complainy, I'll throw in my 2 cents on the platform as a whole. I love it. I really do, but my biggest gripe, one I'm sure most any Android Developer here knows about: Audio Latency. I know that you guys are working hard on getting the visual elements of your os going, but sound is a big deal too. Dreaded issue #3434... which is actually more than just one issue. (http://code.google.com/p/android/issues/detail?id=3434 if you don't know what I'm referencing). If you think you're over budget with only 20ms to figure out what to draw, try a full 100ms or more (sometimes 200 on a galaxy s 1, the lowest I've heard of being around 50) then trying to do anything with it like spectrum analysis and drawing a spectrum analyser to the screen with any accuracy using an audio source bitrate greater than 8000kbps. Sorry about the off-topic rant, but I feel like this article is getting some good attention and that particular issue needs all the attention it can get; without it the market for Android Audio applications will always be severely crippled.
 
60fps, you have 20 milliseconds to handle each frame. How Did iOS handle it. I mean for real, no politics but the smothness of ios3 is not even comparable to icecream.oS
 
+Michael Morrissey , that is just one example why iOS is a superior development platform. With OS X used as its backend, Apple is was able to port their Core Audio and Core MIDI frameworks to a mobile device (also their Accelerate framework, which is incredibly efficient at DSP operations, such as FFTs). I imagine there are no audio engineers at Google, whereas Apple has multiple departments devoted to such things.
 
+Jonathan Dickinson where have you been? Dual core phones are already out, and they are still sluggish compared to iOS devices. Just throwing more CPU cycles at Android is not going to fix the problem. The fact that a Google engineer felt the need to explain why Android is sluggish says a lot. I don't see Apple explaining bad performance. I just don't get your point at all.
 
Unlike +Rory OConnell , I do give a fuck & am pleased to see the constant & consistent improvement of the Android platform.
I have been an Android aficionado since before installing version 1.6 "Cupcake" on my T-Mobile G1 (HTC Dream), which I still own; it even runs 2.1 "Frozen Yogurt" well enough to be relied upon for daily use.
Presently I am enjoying smooth performance of 4.0.1 "Ice Cream Sandwich" on my T-Mobile Vibrant (Samsung Galaxy S); it's noticeably better than when I was running 2.3.5 last week!
Keep up the great work & fuck the naysayers!
 
+Danny Patterson Ahh, but did Apple port a MOD/XM tracker player to iOS?? Mostly joking (and plugging my libmodplug port to Android ;)
 
+Rory OConnell good one. The end users don't know about the geeky stuff that happening under the hood, no matter how impressive they may be. Hell, they don't even care about the 'effort' the devs poured in making their damn phones. All they care about is the results.

When the public learned about the Large Hadron Collider, they were more concerned about black holes than Higgs Boson.
 
The end user/consumer is what any successful product depends on to survive and flourish because without that, whatever the product is, it will become fodder for the garbage bin. That's why I posted my previous comments. I want Android to succeed but if Google doesn't stop the fragmentation of Android and chip, handset, tablet, etc., manufacturers abusing the philosophy, letter and spirit of Open Software and abandoning owners of their devices by not providing developers and consumers with what's necessary such as source code, drivers, programming tools, and timely Android updates for existing handsets which can run those updates to make Android a success, Android will eventually become a flash-in-the-pan which masses of consumers initially purchased then lost trust and confidence in. Isn't that's what's happening to RIM now? Didn't that happen to other companies "too big to fail" except for some which recieved oceans of taxpayer's money to bail them out of bankruptcy which Google and the handset manufacturers won't be getting if they get into serious trouble. Android needs what I posted earlier. I still haven't received an answer from Google.
 
Danny Paterson - It's a superior development platform in that way I suppose, but let's not get ahead of ourselves. For a Techno Engineer such as yourself (I'm a DJ/Developer/EE Nerd myself), the CoreAudio libs are definitely infinitely more mature and polished. On Android, however, it isn't too much effort to find a decent java implementation and spawn an AsyncTask to handle it in a different thread, and if that's still not fast enough there are C libs for DSP you can use in the NDK without too much trouble. I've run into different but equally troublesome problems with sound on the iphone. The problem is that not in software at all, but the actual hardware. It doesn't exist on the ipod touch which is odd, but the iphone has an analog high pass filter before the ADC, which cuts the low end on recordings when using an attenuated stereo -> 1/8 mic plug (I know it's a mono input, but regardless, the same exact cord and code recording on the two devices produces a very distinct detectable result). A shame remedied by using a different but much pricier USB Audio ADC like the iRig. Anyways, sorry for the thread jack. Again, great post Dianne.
 
Hmm.. I'm dubious at your "true" facts, no disrespect. I failed to find any references or sources for any of your claims.
I would certainly like to know how you came up with some of those numbers (especially memory requirements for OpenGL).
 
Makes one thing clear to me that i shouldnt expect performance on Galaxy nexus any smoother as compared to SGS2.
 
+Antonio Correnti That article is from "cultofmac" and puts Android in a bad light when compared to Apple. Did you really think it would ever ever ever be unbiased? The author doesn't even try to seem unbiased.
 
+Antti Urpelainen Good insight there Antti! Thanks!

However FPS vs. Refresh Rates are not in sync all over the place. Games produce variable frame rates depending on the scene and number of objects to render, while monitors are flashing at fixed rates, and each at different rate. There is a VSYNC option, but is that the case for mobile displays? Is framebuffer synced by the display?

Mobile displays will flicker at different rates too. Admittedly there is less variability in mobile displays, but still. OLEDs will be clocked differently than LEDs etc. I can imagine that lower-end tablets will be refreshed slower to save power but also as a result of memory bus bandwidth limitations of cheaper memory controllers.
 
Hi Dianne, can you comment on the lack of USB Host feature on the galaxy nexus?
You advertised this feature in manuals but no one is able to use this features without custom kernel, why?
Thanks.
 
As an Android dev, would suggest the Android team to perform a public contest with good prizes to propose some better ideas on this, i bet there are some great hackers interested on this!
I in point of view, the whole Android ecosystem is suffering a lot with this, i see a lot of people mangling about when in tech stores they compare ios/android...
 
Android will always be a challenge for developers and frustrating for consumers.
 
+Rory OConnell the number of important bugs that Google does not bother to fix or sometimes even comment on is not a trivial one: I am still amazed at how they still have not found the time to fix the over-reliance on NITZ (instead of NTP) to keep the clock in sync for example... clock drift is a huge issue on many handsets and especially on WiFi only tablets.
 
If you want an iOS experience, then go buy an iOS device........sheesh. It's really that simple. I'll keep my android, true multitasking, and open environment.....and if that means occasional lag or choppiness....so be it. There are some really rude people in this thread, but thankyou +Dianne Hackborn for trying anyway.
 
If hardware acceleration were the only problem then I'd own an Android Phone immediately - the sad reality is that within 3 months of purchasing an Android phone the vendor has abandoned providing any sort of software support in favour of ramming the next version do your throat. Take the Motorola Defy from Telecom NZ (in New Zealand), you spend NZ$399 on a phone and you're sh-t out of luck if you want to upgrade to 2.3.x let alone 4.0. Ok, then how about Samsung Galaxy S II for NZ$999 - comes with Android 2.3.x but where is Android 4.0? where is the official announcement of a release date?

Quite frankly until Android problems are properly addressed by Google it won't matter how many blogs are posted on peripheral issues given that for many people like me Android phones are just unworkable when compared to the iPhone that has consistently had 3 years of iOS upgrade provided.

Btw, the fact that Google fails to sell its phone to NZ customers directly tells me it isn't interested in actually doing anything useful other than to whine about how they have it 'tough in the marketplace'.
 
Thank you Dianne. It's great to get some insight into how things work under the covers.

Looks like there has been a lot of "Mine is better than yours" here with respect to iPhone and Android. They both have their strong, and not quite so strong, points (I know folks who develop for iPhone and I work on Android). I think a lot of what we see with respect to lag on the very high density devices (I have an LG Nitro on the way...interested to see how it does running a dual core 1.5 with 1280x720 resolution) won't be an issue within the next few years as the hardware continues to advance. That said, it's not that bad today to me (of course as an Android developer I might be a wee bit biased...LOL).

As for the issue about Google addressing bugs or not, I know we have had this discussion before in another forum. Some of us would like to see the new enhancements put on hold in order to focus on fixing bugs and creating better documentation, but one can hardly argue with the success of Android, so what you are are doing is working from that standpoint. Just hope there is some budget to get to the more egregious bugs and lack of documentation in 2012. :)

Anyway, long story short, please continue to give us these sorts of tidbits. It's beneficial for sure.
 
+Kawaii Gardiner Agree. official updates are really slow. google should try to do something about it.
After reading entire post, I still don't get the root cause.
Does google find a way to solve? If yes, when can we expect that, smooth animation/scrolling?
 
thanks for clearing that up Dianne, but Google's brand is getting dragged through the mud because of Carriers spitting out garbage devices bearing "Android". Don't know what it's like in the USA, but up here in Canada there's zero incentive for Rogers (or anyone) to maintain latest versions of Android OS releases. They're still selling phones with 2.0 slapped in them. YUK. It's a big "FU" to the consumer and the carrier can sit back and redirect all blame to Google.

I love my iPhone, but only because of how bad the Android situation has become. Google needs to bring the hammer down and renegotiate all their contracts with the carriers to fix this problem.
 
Yes, Google is getting blamed for Android fragmentation and lousy/buggy implementation which is right and just since Google has/had the ability to strictly require that any manufacturer which uses Android must provide timely updates, within 2 months of an update or new release of Android, for as long as the hardware can accommodate the update whether that's 6 months, 1 year, 18 months, 2 years, etc. and, if the hardware manufacturer doesn't comply, that manufacturer loses its license to produce any more Android OS devices until Google deems that manufacturer to be in compliance and the manufacturer must provide a substantial hardware warranty extension on all hardware for which the manufacturer wasn't in compliance. There could also be monetary compensation and other penalties which would be paid to Google for not being in compliance. Essentially, it would be a "Bill of Rights" for consumers of Android OS devices which Google would enforce. I don't think device manufacturers would dump Android because they're getting it for free (except for those which are paying extortion money to Microsoft) and to provide their own OS would be much more costly and not have the utility and apps that Android has.
 
Wouldn't a comment from +Larry Page be good right about now? Even to just say "I acknowledge this valuable feedback from people who CARE. The buck stops with me."
 
A Google property that shows extreme lagging: Market. Why should UX on Market lag, or commonly stop, just because it's downloading or installing in the background? It's inexcusable sloppiness from Google in a showcase application, and a perfect example of how little they really care about this issue.

There's a reason why tty keyboard interactivity in Unix runs at a higher priority than most system processes and threads. This has been a solved problem.

With all this fragmentation on Android, CyanogenMod is the only one that reunifies most Android devices back together in a supported platform again to support even orphaned devices, little thanks to Google.
 
"The real important difference between these two screens is just that the Galaxy Nexus has 2.4x as many pixels that need to be drawn as the S2. This means that to achieve the same efficiency at drawing the screen, you need a CPU that can run a single core at 2.4x the speed" - Then why did you guys decide to put such an under-powered GPU into the Galaxy Nexus? It's basically an overclocked Nexus S GPU isn't it?
 
I agree Market is quite laggy (due to it downloading the bitmaps in the Market) as well as navigation (swiping up or side to side) on my Nexus S. I compared this to the Samsung Focus (Windows Phone 7) and its market is way way way more smooth. Its the same hardware, so that must mean the software sucks!
 
Don't even get me started on the Motorola Milestone XT720 support fiasco...new phone with no upgrade/update past 2.1 !!! Shameful!
 
So GPU is much more important when it comes to drawing the pixels if the system pushes that task to the GPU, and not leave it to CPU...
no wonder qualcomm processors are not smooth, those slow GPUs...
 
Real nice explanation of the thing that is the most talked about when it comes to comparing Android with iOS. And I am sure with time Android will simply keep getting better on the display part with the advent of ICS and future Androids :).
 
So,GPU is so important.....
 
Is it possible for OEMs or developers like CyanogenMOD / MIUI to enable a high priority thread for UI, like scrolling and such? Right now the priority thread is set to normal, thats why it has micro lags everywhere.
 
Thanks Dianne

For me problems are:

+ programmers write wrong code ( for example ListAdapter::getView() doesn't reuse convertview, too many objects for GC, I/O operations in UI thread )
+ first measurement problem on heavy views.

Let me explain the "measurement problem".

Well, it's the biggest advantage of android UI toolkit. It allows you to make UI which works on every screen size. You can do everything relatively which is cool. If you ask iOS programmer, he/she will tell you that he/she will place a widget at position (30,30). Android programmer will say - I will put the widget "under something" or "align it to the top border". So what is the problem? ....measurements goes in UI thread. Ok, that's fine, measurements are calculations, it's just CPU so it's for free. Well, no, it's not for free. Try to override the onMeasure method of your root view and count the time. You will be surprised. Also If you have a free time, please have a look at onMeasure method of the most used android widget: http://www.google.com/codesearch#uX1GffpyOZk/core/java/android/widget/TextView.java&q=TextView.java&type=cs&l=5248

The solution would be to create views in separated thread an force them to measure, so their are ready for drawing and binding to view hierarchy.
 
Java will be always slow, too many GC, why not use ObjectPool instead?

post from cnbeta.
 
nice post Dianne....in fact i never knew these thing before though i have spent more then 2 yr in Android Development ...Thanks a lot again for this really really helpful post ......
 
Just wanted to chime in: That this post would generate so many comments was hardly a surprise, to anyone reading the tech press, reviews, blogs, and forums. In fact, "lag and stutter" ranks at the top of android criticism along with fragmentation. What is more important is that +Dianne Hackborn was surprised by this reaction. I say, this post is too late too little. At least a year late.
 
So basically, Android still isn't as smooth as iOS. Google just has a lot more excuses now.
 
Great post...! Provides a lot of insights! Thanks for this.
 
Nice one Dianne, thanks. Looking for more of this.
 
In android ICS and gingerbread, when you open the new google music beta (latest version around 4.1) and going to "songs" and scroll the list there... my whole GALAXY NEXUS's magic just disappeared. How can a simple list like this be laggy?


When you go to landscape mode and go to "recent" tab or "albums" tab, the scrolling is 60 fps at all times/ smoother than iOS. How is this possible?
 
" "Full" hardware accelerated drawing within a window was added in Android 3.0 "
Implementation isn't completed. How about clip*() and other methods? They haven't added yet
 
Ok, first off in the real world 20ms makes not 60fps. You are off by an incredibly large margin there so thats worrying.

Second you guys might have better luck at GPU acceleration if your APIs were well thought out to begin with, because when it comes to putting pixels on the screen nothing beats the GPU in terms of efficiency and the world has known this since before the first line of Android code was written, so why does it feel like an afterthought? Sure, its possible to max out the bandwidth blitting from the CPU and while that might get you to 60hz with even fairly dumb code, its not energy efficient which is kind of important. Android to me feels like an OS suffering from some incredibly bad legacy issues, and its not because its old, its because you guys fell into traps the rest of the world solved 10 or 20 years ago, and I am not just talking graphics here. It can be fixed, but step one is probably making the NDK a first class citizen.

Third, while I don't think rendering the UI should be done on the CPU you must be mental to think thats not a parallel operation, even for "a single app". How do you think GPUs do it?

Also, from your description of how Honeycomb is rendering the UI, it sounds like you are throwing away buckets of performance on rendering a full screen quad to tint the background black. You know, might I suggest something that will remove 1x blended fill? DONT DO THAT! Want to tint the background black? Well just tint it black when you render the background! Just setup a color multiplier uniform or something!

At the end of the day its clear iOS devices are trouncing Android devices in terms of responsiveness and smoothness, even when you take an older iOS device with inferior hardware with high density display (iPhone 4), its still smoother than an Android device with much more powerful hardware. So its obvious this is largely due to software, rather than hardware. And don't go blaming PVR's driver or whatnot, take some god damned responsibility, Apple isn't hindered by their driver after all, granted they branch and maintain their own version, but they didn't just hit a wall and blog about it, they asked themselves 'how can WE solve this issue", and they did this in 2007 and never looked back. Hell even with their driver it really shouldn't be an issue since there can only be 1 active GL app at a time really.

And in the end if you feel you guys really are bumping up against the limits of your hardware once you sort your software out and still not getting the smooth experience your customers demand, might I suggest not doing effects that you can't handle? You know, design your software and content with the hardware in mind. You guys are in constant contact with device and chip makers, maybe try designing with their products in mind, and test on their hardware, if you are not 60hz and smooth as butter then cut shit until you are. If countless game developers can do it, I think Google with its 30,000 employees and billions of dollars can.
 
does someone get the article translated to spanish pls, ?
 
You rawk, thank you for article, been trying to figure that out for a long while, and thanks to droid-life for sending me here
 
well shawn im still not finished yet but working on the touch up hopfully i get a crew working with me to finish thanks i still need a apliacatioon
 
All I know is that I won't be buying anything Android-based until the lag issues are resolved... and Apple is evil... so where does that leave me?? :(
 
+Dianne Hackborn thanks for explaining all this. Though what I still don't understand is if the dashboard, launcher, desktop, etc. are built into Android (I'm on the Galaxy Nexus right now) - why are THEY not butter-smooth? There's still noticeable lag when I try to swype to left or right of displayed set of icons on teh desktop. Also laggy when pulling up the launcher, etc. This does not leave me with a warm fuzzy feeling inside considering I just upgraded to the Galaxy Nexus from my 3 year old iPhone 3G which had these things better than butter smooth!
 
I honestly don't care what about the details of mentioned above. I KNOW one thing for certain as an Android user, the UI lags terribly compared to iOS. FIX it. Let's stop dancing around the issue, all Android devices are plagued with this seemingly disconnected UI rendering issue. I can't tell you how many times i pick up the damn iPhone and the freakishly insane responsive no Android device has provided. I've had just about every major Android phone out there and its all pretty much the same.
 
Well, you always mention "fast enough CPU,, fast enough CPU.." However, have you ever concern about the performance of your competitors' products? Can you see the fact that, when Apple was making their iPhone3Gs or iPodGen3 with ARM Cortex A8 processor plus PVR, these devices' UI experience were already very nice. You know, at that age, the ARM Cortex A8 processors used is not Apple's A4 and is not amazingly faster than other A8 processors like OMAP3series etc. Still, performance of these devices are nice, smooth enough... It is disappointed to see that Android devices can't achieve the same thing with 2X faster hardware and its software engineers still blame on the use of slow processors and always try to request for faster hardware in their words....
 
Well, this all sounds great now...BUT, what excuse are you going to come up with when the iPhone 5 comes out with a 720p display that runs graphics, transitions and animations buttery smooth? The reason why the iPhone is so much smoother and better is because Apple doesn't tolerate excuses. You Google people should already know this, most of you use Apple hardware at work because it's the best. Google products will never be the best. Well, maybe the best at coming up with excuses for not being the best.
 
I wrote an app that doesn't use any android widget to draw its UI.
The UI is written using a full canvas. Every widget drawn is written using canvas so I use many drawLine(), drawRect() and other similar methods. The UI is really smooth also on slow phones but it became laggy when I enable hardware acceleration on my galaxy nexus also. I would like to enable hardware acceleration for image transformations improvements but I can't do it since it slow all my UI. Why it slow my UI? Is there a reason? I heard about many other people that seen bad performance on canvas when hardware acceleration is enabled. What is the reason of this performance drop? Thanks.
 
"Some have raised points along the lines of Samsung Galaxy S2 phones already having a smoother UI and indicating that they are doing something different vs. the Galaxy Nexus. When comparing individual devices though you really need to look at all of the factors. For example, the S2's screen is 480x800 vs. the Galaxy Nexus at 720x1280. If the Nexus S could already do 60fps for simple UIs on its 480x800, the CPU in the S2's is even better off.

The real important difference between these two screens is just that the Galaxy Nexus has 2.4x as many pixels that need to be drawn as the S2. This means that to achieve the same efficiency at drawing the screen, you need a CPU that can run a single core at 2.4x the speed (and rendering a UI for a single app is essentially not parallelizable, so multiple cores isn't going to save you)."

If you guys already knew this, then WHY ON EARTH did you put a 2yr old GPU/CPU into the Galaxy Nexus? The entire blogosphere was wondering why Google made such a stupid, backwards move (on their FLAGSHIP device) and it looks like you've confirmed that they were all correct! It was a stupid, backwards move.

On the next NEXUS device, don't put 2yr old hardware inside it, put the next generation hardware inside it!
 
Here my hopinion on Android Hardware Acceleration.
http://groups.google.com/group/android-developers/browse_thread/thread/4e33ca5493885142
a choppy experience for most apps, ICS is really a good project and I love it but you can't hide that it has some serious performance issues when hw acc is on.

@ Caroline Nguyen, the problem isn't in the GPU but in the optimizations inside the ICS. As I explained on google groups hardware acceleration bringed new performance issue and quite every third party apps are affected. You can see this problem whit quite every third party apps that heavily uses the paint methods to draw its UI. In any cases the SGX540 built into the nexus is a 384MHz one limited to 308MHz for some reason. It isn't the same GPU you have seen on Nexus S but it's a new GPU inside a new SOC. Galaxy Nexus hardware isn't anything special but it isn't a bad one. OMAP4460 can do good things with its horse power, the problem is in the ICS optimizations and in the hardware acceleration issues that we are experiencing since honeycomb.
 
Great post and great explanation, but it is still words. iOS is supersmooth, WP7 is supersmooth, but all these technical things stops Android from being smooth? Seriously, you should stop adding features and take care of the ABC of UI experience first. The UI should have been mature a long time ago. Everytime I sit down with my Galaxy 10.1 I just get pissed after a few minutes and get my laptop instead.
 
Really interesting post and explained a lot for me. Really hope that ICS will improve upon the android systems, because 2.3.5 on my S2 is just bland.
 
Interesting thread, which gives many answers, but also rises many questions. For example
- How can it be that there, in the Internet, is so many misleading writings about how Android works? Even Android developers write rubbish (as claimed here). How can one assume that an Android developer optimizes the code in the right way if he does not even understand how stuff works? Why there is no Android "white paper" or proper documentation to refer to, to avoid confusion and end all speculations? Isn't it time for Google to look at the mirror as well?
- Is there really no independent benchmark for UI responsiveness? If there really isn't, it would be really good idea to develop one. This would make comparison of different OS'es, and also different hardware platforms for the same OS, much easier. Of course one benchmark number is not able to tell everything, but it would give some sort of quantitative measure and stop endless arguing.
 
Thanks for a very good post.
However, this part about 20ms not being a lot of time --- really ?
I remember programming games for Sinclair Zx Spectrum - with no GPU and the 3 MHz (three MegaHertz) CPU clock we still had our 50fps. Or, every other game on a Commodore Amiga was playing music and showing smooth 50fps animations (or 60fps in the US) while loading itself from the floppy drive on a 7MHz CPU. There were no dropped frames nor audio glitches.
THOSE were the times to complain about 20ms. Not today with 200x faster CPUs.
None would even think about touching a filesystem in the drawing thread back then ... That was 20 years ago -- and now it's a big problem ?
Man, programmers just got really lazy :-)
 
I used to have an Amiga too (still do, in fact), and back then games were simple, resolutions were low, and all background stuff was killed off to achieve those performance figures. And since the hardware was quite simpler, the programmers could code "to the metal", which is something no sane person will attempt today. Today there are too many abstraction layers on top of the hardware - which make it possible to code bigger (and more portable) programs in reasonable timeframes, but of course this is also why we are not getting the performance improvement in software like we do in the hardware.

Long time ago I used to be in visual simulation business (which is just custom made games with no music, running on exhorbitant hardware). Even though I am not a programmer, I know that perception-wise a touchUI and a vissim game is the same thing, without instant feedback the illusion of control shatters.

Anyway. "Lag" and "smoothness" of the UI are two seperate things. Lag is the reaction time between input and some sort of discernible output, we also called this Latency. The smoothness is the actual (preferably consistent) frame rate of the output once things begin rolling.

A few days ago I played with the Samsung Note, the international 3G version. It is an interesting device, the screen is wonderful, the hardware is quite cutting edge, and it is surprisingly useable despite its size. I was also dismayed by the amount of latency of the user interface. The response time of swipes were quite behind what I have on my stock 2.2 HTC Desire, which is obviously quite older and slower hardware. On the other hand the Note was "fluid" (no stutters, missed frames) once things began rolling, which is to be expected.

I have a few suspects on what could be wrong with the Note, beginning with the UX Samsung overlaid on top. There was no way for me to test this, since the device wasn't mine.
 
+Tankut Erinc The irony is Dianne is from the Amiga scene ... If they only treated UI like a video player: it cannot drop frames, and it has to respond.

After playing with NativeActivity and seeing ALooper_pollAll v ALooper_pollOnce, that latency maybe be entirely framework due to poor ideological choice between the two ideas.
 
Good information, but with this info, the UI performance of the Android device still remains the same and there is nothing much I can do more to improve it.
 
DISAGREE : Aren't we fooling ourselves?

Hardware rendering on GPU isn't a silver bullet : Agreed

If using CPU only, a single process' renderer can't magically get better using multiple cores: Reasonable

Num pixels * color depth of the display combined with a particular hardware (GPU, bus, ...) decide if we can draw n number of times within 16.67ms aka 60fps : Cool.

If we alpha blend three images, all of screen size, we've already outrun our budget: Fine.

Resolution disparity between S2 (800x480) and Galaxy Nexus (1280x720) is big; so stop comparing: OKAY

iPad has a comparable ARM based dual core 1GHz CPU but a quad-core GPU. It manages to drive QXGA (2048x1536) that's a million pixels more than DOUBLE of Galaxy Nexus. Those engineers don't complain. It is silky smooth.


iPhone 4S has a weaker CPU and 2/3rd the resolution of Galaxy Nexus and they don't go around complaining either.
<b> Oh love android and respect Dianne's contribution here but we can't get away fooling ourselves that it can't be done when the competitor does much better with pretty much the same hardware. There's nothing wrong in learning how they handle it. </b>

Or should we do more in C/C++? Anyhow Dianne Hackborn, please expand the official APIs in NDK. Struggling to access camera buffers, surfaces etc in a consistent way across versions except through slow Java/Dalvik SDK which doesn't guarantee avoiding copy across JNI.
 
Brilliant post, and all from a black and white cat!
 
Isnt it true that android is there to compete with iphone. So it began as a catchup game. On top of that they had lofty goals(java in embedded, automatic adaptation to screen size, can run on a variety of hardware). All of these is starting to bite back.  And the feature creep is the icing on the cake(face recognition to unlock, remote disabling of phone). This shows lack of focus.

I really wish android was like google search(always works, unobtrusive).  Nevertheless, I am hopeful of the brilliance of google's engineering team
 
Look at #Firefox 14 on #Android. The UI is silky smooth even on a now ancient HTC G2, on Android 2.3.7.

This, plus silky Opera, is all the core evidence needed to say Dianne's assertions are full of s*hit. It still squarely points at Davlik/Java/gc and Android framework as the source of all UI lag and unresponsiveness.

#ICS? DOA, and doesn't address this meaningfully.
 
Project Butter announced : finally acknowledging the issue ?
 
+Joseph Lee Would you like to point to any of the statements in my original post that were incorrect.  As far as I know, they are all completely true.  And not really related to your comment here.
 
+Paul Santana These things can always be improved; I don't think any platform is perfect in this regard.
 
+Dianne Hackborn "These things can always been improved". Come on, you know what we want, stop pretending you don't get it :
- scrolling that sticks to the finger like on iOS. Use the Project Butter demo hi-frequency cam to compare with an iPhone, you'll see.
- immediate action when button pressed. Same comparison method.
- no hiccup. Your eyes will make the job.

Depends on the hardware, on the app ? OK, take your GN and test the stock home app.

Is that precise enough? 
 
+Dude Kartaguez Until you get Apple to stop suing people and deposing me, I won't be touching an iPhone. :p

At any rate, I am perfectly serious about "these things can always be improved."  From what I hear, the iPhone isn't perfect in this department either.  I can't speak to iPhone vs. Android on this because, seriously, with Apple's current behavior I don't want to go near the things.
 
Indeed, if you can't touch an iPhone, the gap is hard to visualize... Believe us, iOS world is smooth/fast land compared with Android and I'm sure you'll have a chance to visit it some day :-)
 
"rendering a UI for a single app is essentially not parallelizable, so multiple cores isn't going to save you": This statement is either plain wrong or I don't understand what you mean.

From my experience, the best solution to take advantage of this multicore is to first use it to do asynchronous rendering (this make it possible to go back to the main loop as soon as possible and let more CPU time to the application logic). Asynchronous rendering can then use OpenGL for the rendering (the bonus is that you reduce the chance to block on buffer flipping, texture upload) or do a multi pipeline rendering (basically you divide your screen in N area, dedicate one to each core and clip all your drawing request accordingly and marshall the power of you multi core CPU). Of course you need to pay attention to lock and cache issue.
 
post Project Butter analysis (sorry, I don't have notifications turned on):
* +Dianne Hackborn's assertion that the huge touch/UI mis-sync wasn't fixable was very wrong. It is now seems mostly fixed from, probably, the driver-level and up. Finally, good show.
* Another assertion these UI issues weren't really fixable was also wrong. #ProjectButter silently bows, wholly admits, owns up that it's a Android problem instead of just Apps, and finally attacks it. Good model to follow for others except for the denial.
* Bandwidth limited when trying to GPU touch every pixel @ 60fps. Well, you went to triple-buffering to band-aid that. Ever considered Nokia's swap-buffers extension where it only updates a small portion of the frame-buffer? Also, how about DMA/blitter operations directly on the framebuffer for "scrolling" to cut overdraw? Doesn't work well with translucent. Or even multi-texturing so you can avoid drawing textures/surfaces one-by-one (overlays are partially another way).
* Why does Google underspec the GPUs for Nexus devices if it has such a bandwidth problem for the display resolution? Samsung's approach has seemed to overspec.
* Android still needs 2-4x the hardware to approximate iOS. GoogleMaps is still 30fps vs an iPad2. Referencing my good-friend's #CFBench , I still blame the inefficiency of using Java (4-5x IPS loss) vs a fully-native renderer, even on the Nexus 7 with #JellyBean .

* +Daniel Rose Project Butter is effectively a "game-engine" rendering system now. How silly do you look now?
* prioritization (project/OS) was made so that framework rendering OS-priority is now very high. Great job.
* Market lag is fixed in JellyBean, though still exists in Gingerbread. It's too bad you couldn't decouple your UI framework from the OS so you could independently update older OS versions.
* tty keyboard interactivity is still bad evidenced by laggish key-repeat in URL bar in Chrome on #Nexus7 .
* is the timing issues with sound fixed (and generalized), or only the graphics renderer is getting special attention?
* Anandtech's Nexus7 review suggests Android devices uses inferior nand controllers that cannot handle randomized i/o well. So, until MBA bean-counting allows SSD-level controllers, any background i/o will degrade the Android UI.
 
+Joseph Lee I honestly don't know how to respond to your statement "Dianne Hackborn's assertion that the huge touch/UI mis-sync wasn't fixable was very wrong."

I mean...  what the heck?  Where have I ever said that this wasn't fixable?

All I wrote in this post was actual true facts to counter a lot of false information that people had been throwing around.  Is there something I said there that is not true?

If you want to put my commentary into some summary it would be: "a smooth UI is much more than just hardware accelerated drawing."  The work for JB is clear proof of this -- most of the changes were not to do HW drawing (we'd already been doing full HW drawing since HC), but to look across the system for ways different parts are interacting.  Thus a significant part of the improvement was to time all of the drawing against vsync of the screen, and also time event dispatch against that, as well as interpolating touch data with that to have it match the updates in the UI.

And a lot of the improvements for the smooth UI were done in the apps themselves.  This was systemic work.  There is no silver bullet.  One of the important tools for all this work was systrace, which yes was used to analyze the behavior of the framework, but also for a significant amount of app behavior that needed to be improved.  (Which is also why we made this tool available to app developers, because it is extremely important to have it to be able to make their own apps smooth.)

To dig into some of your other statements:

- "I still blame the inefficiency of using Java (4-5x IPS loss) vs a fully-native renderer, even on the Nexus 7 with JellyBean" -- this is quite inaccurate.  The renderer is fully native.  The only part running in Dalvik is the app code that issues the drawing commands.  Those drawing commands are in display lists so transformations on them don't require even executing Java code to regenerate them.  Trying to make judgements like this based on comparing the iOS maps app vs. the Android maps app is pointless, since they are completely different code-bases, totally different architectures.  I mean...  I am pretty sure that the iOS maps app is still using bitmap tiles while Android maps uses vectors.

- "Project Butter is effectively a "game-engine" rendering system now."  Not any more than ICS was.  There were no fundamental changes in the graphics architecture in JB, the work was almost entirely about tuning and optimization.

- "Market lag is fixed in JellyBean, though still exists in Gingerbread. It's too bad you couldn't decouple your UI framework from the OS so you could independently update older OS versions."  You do realize that these kinds of features usually require significant new features down to the graphics drivers?  For example the vsync facility in JB requires support in the graphics driver to enable it.  The hardware accelerated drawing in HC requires extensive new support from the graphics driver.

- "tty keyboard interactivity is still bad evidenced by laggish key-repeat in URL bar in Chrome on Nexus7"  Is it slow elsewhere?  No?  Good chance it is an app issue.
 
Sorry to continue beating this dead horse but you wanted a quote:
+Dianne Hackborn "For example, drawing a list involves way more than rendering to the screen. You have a touch screen processing low-level input in firmware to generate the higher-level touch data [...] Issues can happen at any point in this process, and I have certainly seen a number. And it is ridiculous to say that this interaction can't belong to the application [...]" This is where I interpreted that touch-sync events aren't fixable. Yet, JellyBean tweaked this enough in a managed way that it's better.

I still think a fully-managed list-widget animator (or generic framework level animator thread based on that new Choreographer) is the way to go. Personal recent work with Clutter, and noticing Chrome's new threaded scroll animator cinches it.
 
Just a sidenote, on the good old #Amiga  , to get the best performance of it you had to clear half the screen with the processor to get some more cycles, and the rest of the screen was the blitters job. Nice to see those good old tricks still works in a way :-)
 
Thanks +Dianne Hackborn I was fishing with Bing for some explanation of the window animation selections in the 4.1.2 jellybean update to my SGH-i727 Samsung GS2 Skyrocket.  All default to 1.x  So, I just tried a few changes.  I think I see what they are for.  And thanks to your article why that is so.  Interesting.  I will have this on contract another year so I might as well clue myself in on what is going on besides a ding when hate mail is delivered ;)
 
I can't even find any examples to go from EGLSurface to an FBO with SurfaceTexture (3.0) or TextureView (4.0).   I need to draw to an FBO, then I want to go back to the EGLSurface.  

These and GraphicsBuffer are not exposed to the NDK.  Pbuffer's are obsolete.  Pixmap's aren't really supported, and a host of eglGL extensions are either obsolete or unsupported.  I think there's a lot more needed here in the API than just explaining that GPU support is available.
 
I'm also finding that the simulator can't handle anything but point sampling, and doesn't emulate GL_EXT_shader_framebuffer_fetch?  These are big obstacles to Android GPU development for me. These should be getting forwarded to the hw or sw rasterizer underneath.  I'm finding that I have to have many shader variants if I want to support both the AVD and corresponding hardware.  iOS updates keeps the simulator and hardware calls in sync.
 
Of the new-gen OSs, (iPhone, Windows Phone, Blackberry 10) only Android still has "dropped-frames" UI even after "Project Butter".

The lack of threaded, lock-less rendering (like a video-player -- solved problem) still hurts even the Galaxy S4 today with its monster hardware. It's embarrassing.
 
The galaxy s4 has the terrible touchwiz interface.
Android is buttery smooth on nexus devices.
Add a comment...