Android 3.0 Hardware Acceleration | Hacker News Reader

Android 3.0 Hardware Acceleration

android-developers.blogspot.com

61 pointsshimi27 comments

I tried out the Xoom, and the browser still felt like an Android browser. It didn't have that super-smooth feeling you get from an iOS device. If it's not hardware acceleration, then just what is Apple doing that Android isn't?

Android does a lot more reflows than iOS. iOS zooms by first scaling a raster image of the page and then reflowing after a brief delay of user input. That kind of resize is very fast, whereas a full HTML document reflow is slow.

iOS does that thing were the page sits still till it realises you're scrolling, not clicking, then accelerates towards your finger then decelerates again as it approaches your finger. Android (at least as of 2.2) seems to just snap to your finger once it realises you're scrolling. Could that be it?

The browsing on an original and even 3g iphone are so enranging that they almost make me homicidal - so I think what you are seeing is a rev 1 vs a rev 4 product, so I wouldnt compare them in such degrees

Erm, how long has Android been around again? It's hardly a rev1 product, and the iPad was "rev 1" under this definition and doesn't have the same trouble, and had half the processing power.

I'm an iOS developer and an Android developer, and I'm honestly disgusted by the level of excuses that is made for the horrible UX on Android. It reminds me of 10 years ago, when the meme on /. was "The Year Of Desktop Linux is always Next Year(TM)".

Well, I agree with you on some points completely. Though.the ipad was not rev 1 -- which version of iOS did the iPad run?

While honeycomb is android 3 -- it is a total rebuild.

However, to your point - the UX should be first in ALL of the android space's mind -- ESPECIALLY given that they dont have the design (UX/UI) powerhouse behind them that is Apple.

Do you honestly think they rebuilt scroll views and the web browser completely to get Android 3 launched?

I know from my visits to the Verizon store to play with one that they hype it up as "completely new OS", but other than making the hardware buttons software finally, it looks and acts identically. As technical people, I think we both know that this is a revision of Android, not a completely new OS.

More to your point - iPad ran iOS 3.2 - the 3rd revision of iOS. The Xoom is running Android 3 - the 3rd revision of Android.

"horrible UX on Android"

This is more than a little hyperbolic. Sure, the animations may not run at 30fps all the time. Some animations running at 15fps != horrible UX. I am an iOS dev as well but use an Android phone and just completely disagree on it having poor UX.

It's just an overall lack of attention to detail, compounded with the need for the OS to work on 1000 different kinds of hardware combinations. It's near impossible to describe without sounding whiny or silly, because it's death by 1000 stones, not one killer thing.

Anecdotes:

- Whilst using my Nexus S, it rings. I pull it out of my pocket, only to discover I can't answer it because there's a keyboard over the Answer/Decline buttons. Later, I realize I must have pressed and held on the Menu button long enough while pulling the phone out of my pocket to force the keyboard to popover the Answer/Decline buttons. But why the heck is this possible even? It vaguely reminds me Joel Spolsky's article on the Windows shutdown menu - http://www.joelonsoftware.com/items/2006/11/21.html .

- I want to make it so there's momentum/inertial/bounce scrolling in a text view. This is impossible. Why? So phones that still have trackballs don't have whacky scrolling behavior going on for them. But the ListView has inertial scrolling. How the heck can I possible explain this to my client without sounding foolish or lazy?

- I want to animated a cell disappearing from a ListView. Again, impossible. The solutions mentioned on StackOverflow ( http://stackoverflow.com/questions/3928193/how-to-animate-ad... ) (BTW, the Android presence on StackOverflow is abysmal), in order, and summarized: 1) Rewrite the class yourself because Android is open 2) Some hacky drawing solution that isn't a good idea. 3) Wait till Adobe's dev tools get faster on Android. 4) Re-implement the class from scratch yourself.

I understand now that Honeycomb has much better animation facilities, but we're not seeing that on phones. And when we do, the problem with carriers + manufacturers holding sway means whatever apps I build won't see any improvements on phones until Ice Cream is released and manufacturers ship phones with it. We're talking June or July at this point, right? For basic animation. That was in iOS 1.0. In June 2007.

Whilst using my Nexus S, it rings. I pull it out of my pocket, only to discover I can't answer it because there's a keyboard over the Answer/Decline buttons.

Huh? I'm running Android Gingerbread on a Nexus One, and when the phone rings, I see the usual "unlock" screen, with one option for answering, and one for ignoring the call. There's no way to get a keyboard, no matter which buttons I press.

Is your phone fully awake and unlocked in your pocket? Is there something weird about Gingerbread (or the buttons) on the Nexus S?

Couldn't tell ya. :/ I'll have to test it and get back to you.

On any version of Android, dating back to the introduction of the virtual keyboard in version 1.6, long-pressing on the menu button will pop up the keyboard, which allows you to, for instance, bring up the keyboard in applications without needing a specific textbox to select. This allows you to have applications like ConnectBot, where the entire screen is a terminal emulator, and you can pop up the keyboard at any point and start typing without having to type into a textbox and then "send" the text to the terminal. On the home screen, you can bring up the keyboard and just start typing a search query without needing to press (or even have) the search button or widget.

And for the record, when the virtual keyboard is shown, pressing the back button will always dismiss it without sending the back action to the current activity, so in your case you could have pressed back to dismiss the keyboard, and then pressed the button to receive the call.

Exactly, completely understand where this is coming from - but why in the world is this a default!?

This has happened to me. I'm a geek, so I knew that hitting the back button would get rid of it, but come on. Anyone else in the world would have missed the call while starting at their phone and listening to it ring.

I had the same feeling. It's not just in the browser, it's throughout the whole experience, so the raster trick for zooming that's mentioned doesn't explain it completely.

Google really needs to sort it out. It's a shonky user experience that really doesn't need it to be. I was certain that it was hardware acceleration that was missing, but obviously not. There was that bug ticket which indicated that Google thought it was garbage-collector related, but then that was supposed to have been modified in 2.3.

It's really pretty poor, and is certainly not helping to sell devices. Put an iPad 2 next to a Xoom, or a Nexus One next to an iPhone 4, and you really do see the difference. In stores like Best Buy, that's how they're setting up displays, of the two "flagship products". And I'm sure customers are going to go with the Apple product after trying them both.

Apple should really work on having its products displayed closer to the competition then, because this apparently glaring flaw hasn't stopped Android phones gaining popularity to thei point that they're outselling iPhones 4 to 1 in the US so perhaps Google's priorities aren't as messed up as you might think.

Citation needed. Please share the link to information indicating that Android phones are outselling iPhones 4 to 1 in the US.

NPD smartphone sales stats for the US:

Quarter-Year: Android%/Apple% = ratio

Q2-2010: 33/22 = 1.5

Q3-2010: 44/23 = 1.91

Q4-2010: 53/19 = 2.8

You can find graphs from various sources that show a consistent trend for Android (i.e. the sales in the last month of Q4 are higher than the average and much higher than the sales in the first month) if that wasn't already obvious from the quarterly numbers.

My prediction for sales right now i.e. the month of March is about 60/15 but I guess we'll hear the Q1 numbers in a month or so and it'll be something like 3.5 overall.

edit: a final note, this isn't a prediction that Apple sales will fall, they'll certainly grow (though I think their U.S. marketshare just peaked) it's simply that Android's massive growth will expand the smartphone market and shrink their sales share.

Yep. That's exactly why everyone I've ever talked to or come in contact with has an iPhone: the slightly more responsive scrolling behavior in browsers. Total deal-breaker.

(Don't get me wrong, it's a valid criticism. But it's not even remotely close to the reason people choose an iPhone over an Android-based phone, or vis-versa).

It's much more like slightly more responsive behavior everywhere, not just browsers. I have bought cheap low-end Android handset, as I really didn't want to pay a hefty price for the iPhone (Europe, it's very expensive even with subscription, which is expensive as well), it was my first smartphone and I wasn't entirely convinced that I need or even want such a thing. I do, but overal sluggishness of the Android handset (even high-end models that I was able to try for a while did have some lags and weren't really what I expected) is very annoying. In fact, it's the primary reason why I'm now seriously thinking about getting the iPhone.

This matches my experience almost exactly. I wasn't sure that I needed a smartphone, so I got a low-end Android handset on Verizon (Droid Eris), and it's been an absolute piece of garbage, even with custom ROM (currently running a Gingerbread ROM based off CM7). The higher-end Android models I've played with have been better, but even my girlfriend's HTC Desire has boatloads of issues, and some of them are the same as the issues on my Eris (scroll lag, menu lag, poor input responsiveness across the board).

Google really needs to focus on Android's user experience if they want to be a serious competitor to Apple across all market segments[1]. That said, I doubt that Google is going to place a strong focus on fixing Android's UX issues, because it seems to me that Android is yet another platform to get more ads in front of more eyeballs, and if shoveling OS updates and cheap handsets out is the way to do it, then that's what they'll do.

[1]: While it's true that Android has the #1 market share right now, I doubt that it's because of Android's UX attracting the masses--I have a feeling that it's due to Android's low price and availability at said low prices in emerging markets with many fresh-faced consumers (China, India come to mind). I strongly suspect Apple still kicks Google's ass in the all-important sector of consumers with money to spend on phones and apps.

What I notice is that my iPad1 is often just as slow or slower than my Nexus One but the experience is much "smoother" - that is, when you scroll it scrolls smoothly - always. If the rest of the browser can't keep up, too bad, you get some blank areas showing, but at no time is that allowed to compromise the speed of the scrolling, zooming or whatever else you're doing. This must be reflected quite deeply in the code and even the OS I imagine to always prioritise user interactions over anything else. It definitely makes using the devices more "pleasant" even while sometimes it at the same time makes them technically slower or less functional.

Out of curiosity, why is there a flag to enable it? Why not have it on by default? From what I understand, there's no downside to hardware acceleration - the offload to the GPU uses less power, it's rendered faster, and it is a better user experience. What's the edge case that requires this flag to be off?

From TFA:

    some operations behave differently when hardware acceleration enabled

So they've been conservative. I kind of wish they hadn't - 3.0 is a big enough version jump that people understand there's going to be a few glitches, and there are almost certainly a large number of apps that don't use any of the small number of listed APIs that change their behavior under hardware acceleration. Those apps that do use the APIs could be autodetected I would have thought and have hardware acceleration disabled automatically.

I'm planning on doing HTML5 apps for Android tablets. Any word on whether WebView gains any benefits from hardware acceleration yet?

Does anyone else not get a scrollbar on that site?

Known issue, they use some nasty combination of IFRAME and JavaScript for the site that breaks in a lot of browsers.

Reply on news.ycombinator.com