Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Care and Feeding of the Android GPU

satine.org

Post reply on HN
Print view View original

11–20 of 60 posts

Re: The Care and Feeding of the Android GPU

#11

Post by jrockway »

wccrawford wrote: post #2

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. 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 defini…

But the thing is, nobody actually cares about this. I have used an Android phone since the beginning. Touch responsiveness is not something I have ever noticed. Any delay in rendering web pages is due to the network.

I think people that write articles about touch responsiveness or animation latency are suffering from the "benchmarking hello world" problem. Yeah, you could speed that stuff up. But 99% of the time, the phone is waiting for data on a socket, which is not going to get fast any time soon.

Re: The Care and Feeding of the Android GPU

#12

Post by buymorechuck »

jrockway wrote: post #11
wccrawford wrote: post #2

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. 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 defini…

But the thing is, nobody actually cares about this. I have used an Android phone since the beginning. Touch responsiveness is not something I have ever noticed. Any delay in rendering web pages is due to the network. I think people that write articles about touch responsiveness or animation latency are suffering from the "benchmarking hello world" problem. Yeah, you could speed that stuff up. But 99% of the time, the…

Perhaps, but for me, it's absolutely about usability. Whenever I see new Android phones or builds, the first thing I try out is how responsive the scrolling or zooming is. Often times, I'm waiting for Android to respond to my touch, other times my touches are missed completely. These issues cause unpredictability for me and make the phone harder to use.

As phones got faster, the situation improved, until a larger screen was added, which brought things back down again as the CPU burns to keep up. The milliseconds latency here and the stuttering FPS there decreases the usability significantly in my opinion.

I think that there is a group of users who don't notice these latency and animation issues. But I do, and I think many users still unconsciously attribute their dislike for Android to these issues. (example: my brother in law, used several Android Froyo phones extensively before settling on a BlackBerry because it felt "faster".)

Re: The Care and Feeding of the Android GPU

#13

Post by jrockway »

buymorechuck wrote: post #12
jrockway wrote: post #11

Earlier quoted context omitted.

But the thing is, nobody actually cares about this. I have used an Android phone since the beginning. Touch responsiveness is not something I have ever noticed. Any delay in rendering web pages is due to the network. I think people that write articles about touch responsiveness or animation latency are suffering from the "benchmarking hello world" problem. Yeah, you could speed that stuff up. But 99% of the time, the…

Perhaps, but for me, it's absolutely about usability. Whenever I see new Android phones or builds, the first thing I try out is how responsive the scrolling or zooming is. Often times, I'm waiting for Android to respond to my touch, other times my touches are missed completely. These issues cause unpredictability for me and make the phone harder to use. As phones got faster, the situation improved, until a larger scr…

I have never noticed any latency. I blame the manufacturer-specific Android "improvements", as I use plain AOSP and don't have any trouble.

My EVO 4G gets about 24 hours battery life, with moderate usage during the day. (But again, this is because I don't use HTC's build. With their build, the battery life is barely long enough to boot the phone.)

Re: The Care and Feeding of the Android GPU

#14

Post by pkulak »

jrockway wrote: post #11
wccrawford wrote: post #2

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. 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 defini…

But the thing is, nobody actually cares about this. I have used an Android phone since the beginning. Touch responsiveness is not something I have ever noticed. Any delay in rendering web pages is due to the network. I think people that write articles about touch responsiveness or animation latency are suffering from the "benchmarking hello world" problem. Yeah, you could speed that stuff up. But 99% of the time, the…

People care, they just don't know what to call it. People who use iPhones try out an Android device and say things like "it's just not as polished", or just notice that it doesn't feel right. That "not feeling right" is because when you scroll on an iPhone it really feels like there's a piece of paper under the screen that your physically moving around with the tip of you finger. With Android it just feels like your finger is telling a computer what to do, which is in turn doing a reasonably good job of doing it.

Re: The Care and Feeding of the Android GPU

#15

Post by comex »

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.

I'm not saying the GPU is the answer, and maybe 2.3 is the answer, but ignoring the problem is not.

(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.)

Re: The Care and Feeding of the Android GPU

#16

Post by wtallis »

tgflynn wrote: post #5
wzdd wrote: post #4

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. The argument in favour of a GPU-accellerated GUI…

Are those 10ms with a realistic app/usage scenario ? I wouldn't think users would complain about 10ms, isn't that below the threshold of perception ?

A stutter 2/3 of a frame long means there's a 2/3 chance that you'll draw a frame that doesn't match the current finger position, followed by a frame that catches up more than it should have had to.

The ~40ms input lag shown by most desktop IPS LCD monitors is noticeable even though it falls below the reaction time. On a touch display, it should be even easier to notice input lag, because you can see your finger moving and the screen around it not keeping up. 10ms sensor lag may be below the threshold of perception for circumstances like this, but probably not by much. If you add even a few milliseconds of processing lag after your app receives the touch event, you'll be behind by a frame.

Re: The Care and Feeding of the Android GPU

#17

Post by potatolicious »

jrockway wrote: post #13
buymorechuck wrote: post #12

Earlier quoted context omitted.

Perhaps, but for me, it's absolutely about usability. Whenever I see new Android phones or builds, the first thing I try out is how responsive the scrolling or zooming is. Often times, I'm waiting for Android to respond to my touch, other times my touches are missed completely. These issues cause unpredictability for me and make the phone harder to use. As phones got faster, the situation improved, until a larger scr…

I have never noticed any latency. I blame the manufacturer-specific Android "improvements", as I use plain AOSP and don't have any trouble. My EVO 4G gets about 24 hours battery life, with moderate usage during the day. (But again, this is because I don't use HTC's build. With their build, the battery life is barely long enough to boot the phone.)

I've used vanilla Froyo on the Nexus One. It's dog slow. I don't think this problem is isolated to OEM-specific Android modifications (though they certainly don't help).

Responsiveness and framerate-wise, even a simple cursory examination will tell you: WP7 and iOS run laps around poor old Android. I got to play with a Nexus S recently, and the responsiveness is greatly improved over Froyo on N1... but is still noticeably less smooth than either Apple or MS's platforms.

It's an odd day when MS's UX is more polished than somebody else's...

One area where Android's lacklustre performance really hurts usability is diving into menus. iPhone came up with the novel idea of sliding menus - a simple animation that communicates a lot of context to the user (A belongs under B triggers modal window C, all based solely on the direction of the swipe animation). On Froyo+N1 this animation is jerky enough, frequently enough, that this relationship can easily be missed, resulting in more user confusion and worse UI comprehension overall.

Google needs to realize that we are in the year 2011, not 1995. "UI design" is no longer about placing the right buttons in the right places, and animation is often now the defining line between an easily comprehensible user experience and an obtuse one. IMHO graphics/animation performance is the #1 obstacle in Android's way, and the main advantage everyone else seems to have on it (and it's a huge advantage).

When I use a 2.2 phone, my impression is one of annoyance. I don't know if my touches will be detected, and even if they are, I don't know how long I'll have to wait for the phone to respond. Heck, I enjoy using WP7 phones more than Android because of the performance, despite the fact that WP7 is significantly less featureful than Android! Navigating WP7 is a pleasure, and it never feels like the phone stands in your way. I have yet to get this feeling from Android.

Re: The Care and Feeding of the Android GPU

#18

Post by jrockway »

potatolicious wrote: post #17
jrockway wrote: post #13

Earlier quoted context omitted.

I have never noticed any latency. I blame the manufacturer-specific Android "improvements", as I use plain AOSP and don't have any trouble. My EVO 4G gets about 24 hours battery life, with moderate usage during the day. (But again, this is because I don't use HTC's build. With their build, the battery life is barely long enough to boot the phone.)

I've used vanilla Froyo on the Nexus One. It's dog slow. I don't think this problem is isolated to OEM-specific Android modifications (though they certainly don't help). Responsiveness and framerate-wise, even a simple cursory examination will tell you: WP7 and iOS run laps around poor old Android. I got to play with a Nexus S recently, and the responsiveness is greatly improved over Froyo on N1... but is still notic…

I turn animations off. Useless eye candy that just wastes the battery.

Also, is it really fair to compare the N1, a phone that's over a year old, to brand-new WP7 phones?

Re: The Care and Feeding of the Android GPU

#19

Post by eru »

comex wrote: post #15

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. I'm not saying the GPU is the answer, and maybe 2.3 is the answer, but ignoring the problem is not. (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…

Or use a GC that doesn't need to stop the world. (Or at least only does so for very small intervals.)

Re: The Care and Feeding of the Android GPU

#20

Post by vshade »

jrockway wrote: post #18
potatolicious wrote: post #17

Earlier quoted context omitted.

I've used vanilla Froyo on the Nexus One. It's dog slow. I don't think this problem is isolated to OEM-specific Android modifications (though they certainly don't help). Responsiveness and framerate-wise, even a simple cursory examination will tell you: WP7 and iOS run laps around poor old Android. I got to play with a Nexus S recently, and the responsiveness is greatly improved over Froyo on N1... but is still notic…

I turn animations off. Useless eye candy that just wastes the battery. Also, is it really fair to compare the N1, a phone that's over a year old, to brand-new WP7 phones?

Yes, it is really fair. Both the N1 and the WP7 phones have the same screen resolution and the same first gen snapdragon SoC.
Post reply on HN