This isn't the first thing I've seen that Google devs really just didn't get. I think it's from the rapid expansion that Google has done. They get people working on things that aren't really their area of expertise because they wanted to try something in their 20% time.<p>In this case, it's obvious that we've got server people working on mobile code. Future hardware will resolve these inefficiencies? UGH. That's definitely someone from the server world speaking.
Anyone who thinks Android's animation is "fast enough" is either using a faster device than I have ever tried, or has never tried to compare, say, scrolling lists versus the iPhone.<p>I'm not saying the GPU is the answer, and maybe 2.3 is the answer, but ignoring the problem is not.<p>(Edit: So why does a GC pause stop animation, and not just by taking up CPU time, since moving to the GPU would help in that case? Is the animation code itself written in Java and waiting on the GC? If so, I bet rewriting it in C would be a massive help. Also, yuck.)
Apparently touch responsiveness is improved in 2.3. However this article doesn't really explain what's wrong with it. I've been doing latency benchmarks for touch recently, and the highest latency I've seen for touch delivery is 10ms. Now 10ms is pretty terrible for what should be a very straightforward thing, but on the other hand it's only 2/3 of a frame, at 60 FPS.<p>The argument in favour of a GPU-accellerated GUI which is not mentioned here is battery life. I haven't been testing this side of things, but just because a CPU can do a 60 FPS GUI doesn't mean it should. Deferring it to the GPU would certainly reduce power consumption while navigating a UI. Whether this is non-negligible in terms of overall battery life, I'm not sure.
I think the android bug linked in the article is much more informative than the article itself.<p>Basically:
1) Android phones can already animate the screen @ 60 fps in software in most cases.
2) When they can't, it's not because the CPU is too slow, it's because there is other stuff happening (GC, etc.). A GPU can't fix that.
I think the author nails it. Without GPU acceleration Android really is a notch below iOS in terms of UX. In my opinion, even WebOS and Windows 7 have much smoother scrolling and touch response than Android. But if Google wakes up and adds GPU acceleration and better eye-candy, watch out Apple.
Purely by chance, I was trying out a galaxy tab at a store today. I loaded up the Financial Times web site, which took an age because the store wifi was crap and tried scrolling the web page and it stuttered quite a bit at first then smoothed up, zooming as juddery as well. Did the same thing on an ipad - slow loading about the same, but the instant the page was rendered it scrolled and zoomed perfectly.<p>Also the widget for editing the web page URL on the Tab was a horrible usability car crash. What's up with that? Disclosure - iPhone user, but Android curious.
Android's VM can improve perf-wise - see <a href="http://blogs.oracle.com/javaseembedded/2010/11/how_does_android_22s_performance_stack_up_against_java_se_embedded.html" rel="nofollow">http://blogs.oracle.com/javaseembedded/2010/11/how_does_andr...</a>
It doesn't matter what the solution is, but Google need to prioritise UI responsiveness above all else. Until that happens, the UI on Android will suck.