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

51–60 of 60 posts

Re: The Care and Feeding of the Android GPU

#51

Post by ohho »

pkulak wrote: post #14
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…

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…

People do care. They care about price too ;-) Android is heading to US$99 or even cheaper devices (in which I am not sure whether GPU is an option).

Re: The Care and Feeding of the Android GPU

#53

Post by pvaibhav »

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 ?

I work with digital audio/MIDI and a latency of 15-20 ms between pressing a key and hearing the sound is easily audible making it near impossible to play expressive music. 10ms can be felt and is 'annoying', under that is acceptable. I usually keep latency down to 5ms, at most 7ms, only letting it increase, e.g. during mixing when responsiveness is not utterly essential.

Re: The Care and Feeding of the Android GPU

#54

Post by ZPedro »

panacea wrote: post #49
nikdudnik wrote: post #47

Earlier quoted context omitted.

The first thing I've noticed about Android was the overall slugishness of UI animation. And the guy who was showing it to me was amazed by the smoothness of my iPhone 3G UI. BUT YES OF COURSE NOBODY CARES.

If you actually look really closely, a lot of what iOS does with animations are about giving the illusion of responsiveness and smoothness. I'm not saying things aren't incredibly responsive, but some of the animation techniques are used brilliantly to disguise lag. Three examples: 1. Mobile Safari doesn't wait to render what it hasn't downloaded/formated before responding to touch gestures. You swipe and the page sc…

Well, of course. And if you think about it further, all user-facing software is, in fact, an illusion. Smoke and mirrors all the time. Apple just pushes the illusionist work even further than what most software developers (who are themselves illusionists, whether they realize it or not) consider as being "real". But it works, users prefer that.

Not only that, but I'm convinced that users are actually more efficient when perceived responsiveness is added: for instance, most users will not start thinking about what to do next on an app until they are seeing the app interface; presenting then with a non-interacting screenshot as soon as possible actually makes the overall interaction more efficient. But the ultimate is what the guys making PCalc discovered ( http://www.dragthing.com/blog/2009/07/how-to-make-your-iphon... ): you can put a non-interactive screengrab in such a way that even though it is a dumb image, touches will actually be recorded and have their effect as soon as the actual interface is set up; users can actually interact very soon. Now that's badass.

(however, most animation stuff doesn't fall in the category of perceived responsiveness, as most often, for instance for transitions, the end result must be ready before the animation begins; also, "undocumented nature"? Apple's obsession with perceived responsiveness is well-known).

Re: The Care and Feeding of the Android GPU

#55

Post by sedm0784 »

panacea wrote: post #49
nikdudnik wrote: post #47

Earlier quoted context omitted.

The first thing I've noticed about Android was the overall slugishness of UI animation. And the guy who was showing it to me was amazed by the smoothness of my iPhone 3G UI. BUT YES OF COURSE NOBODY CARES.

If you actually look really closely, a lot of what iOS does with animations are about giving the illusion of responsiveness and smoothness. I'm not saying things aren't incredibly responsive, but some of the animation techniques are used brilliantly to disguise lag. Three examples: 1. Mobile Safari doesn't wait to render what it hasn't downloaded/formated before responding to touch gestures. You swipe and the page sc…

Whilst I agree with your main point, I have to nitpick your aside about running iOS on older devices. When I tried iOS 4.0 on my 3G (and the reason I'm now running 3.1.3 again) the UI would frequently completely freeze for several seconds. That can't be explained away as poorly-tuned animations.

Re: The Care and Feeding of the Android GPU

#56

Post by panacea »

ZPedro wrote: post #54
panacea wrote: post #49

Earlier quoted context omitted.

If you actually look really closely, a lot of what iOS does with animations are about giving the illusion of responsiveness and smoothness. I'm not saying things aren't incredibly responsive, but some of the animation techniques are used brilliantly to disguise lag. Three examples: 1. Mobile Safari doesn't wait to render what it hasn't downloaded/formated before responding to touch gestures. You swipe and the page sc…

Well, of course. And if you think about it further, all user-facing software is, in fact, an illusion. Smoke and mirrors all the time. Apple just pushes the illusionist work even further than what most software developers (who are themselves illusionists, whether they realize it or not) consider as being "real". But it works, users prefer that. Not only that, but I'm convinced that users are actually more efficient w…

Thanks for that link... I'm a designer not a developer, but I find articles like that fascinating.

(You are right about the other things you objected to in my comment.)

Re: The Care and Feeding of the Android GPU

#57

Post by rektide »

panacea wrote: post #49
nikdudnik wrote: post #47

Earlier quoted context omitted.

The first thing I've noticed about Android was the overall slugishness of UI animation. And the guy who was showing it to me was amazed by the smoothness of my iPhone 3G UI. BUT YES OF COURSE NOBODY CARES.

If you actually look really closely, a lot of what iOS does with animations are about giving the illusion of responsiveness and smoothness. I'm not saying things aren't incredibly responsive, but some of the animation techniques are used brilliantly to disguise lag. Three examples: 1. Mobile Safari doesn't wait to render what it hasn't downloaded/formated before responding to touch gestures. You swipe and the page sc…

One of the reasons I'd switched to Opera over Mozilla/Firebird/Firefox was because it remained consistently responsive. A page would be freaking out dog slow doing heaven knows what... in firefox, the browser would be frozen, in Opera, I could continue interfacing and issuing gestures and keyboard commands. Even on my old Fujitsu P1120 - a dog slow 800MHz Transmeta Crusoe beast with 223 MB ram - Opera, while not visually responsive, was at least queuing my operations, and would respond as fast as it was able. There didnt seem to be any event queue in firefox; if the browser was freaking out, keyboard commands &c would be outright dropped.

Re: The Care and Feeding of the Android GPU

#58

Post by DaveSF »

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…

This may be related to overall linux interactivity scheduling. There has been a running debate on the Linux kernel mailing list about this for years. The Linux scheduler is more efficient for server-workloads and compiles, but it is not as good for interactivity.

Very recent kernels have a new scheduler which supports a new scheduling algorithm which people are anicdotally reporting better interactivity with. Perhaps this will help the situation.

Re: The Care and Feeding of the Android GPU

#59

Post by [deleted] »

ohho wrote: post #51
pkulak wrote: post #14

Earlier quoted context omitted.

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…

People do care. They care about price too ;-) Android is heading to US$99 or even cheaper devices (in which I am not sure whether GPU is an option).

[deleted]

Re: The Care and Feeding of the Android GPU

#60

Post by biafra »

mikeklaas wrote: post #48
danudey wrote: post #27

Earlier quoted context omitted.

Twelve years ago or so, I was reformatting my home desktop (then a Linux machine) and I decided to try to change things up a little, so I installed FreeBSD to try it out. I figured that there wouldn't be any superficial differences, but I knew that there were architectural ones that I'd run into eventually and maybe I could learn a little more about how different OSes worked. One thing I did notice right away was tha…

Wow, I totally had the same experience with FreeBSD about 15 years ago. I have no idea if it persists on modern hardware, though. Does anyone have a good explanation for this?

At that time the FreeBSDs scheduler was much better than Linux'. I had the same feeling about FreeBSDs responsiveness.

I had a similar perception with Solaris on SPARC. It was slower overall but more responsive when interacting on the shell. Sometimes I had high load (10 or more) and did not notice when using a shell in a terminal.

I think Linux got much better since then. I don't feel the difference on current FreeBSD, Solaris or Linux installations.

Post reply on HN