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

Follow up to “Android graphics true facts”, or The Reason Android is Laggy

plus.google.com

Post reply on HN
Print view View original

41–50 of 118 posts

Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy

#41

Post by ugh »

illumin8 wrote: post #17
interlagos wrote: post #15

Earlier quoted context omitted.

A big part of the delay on the GS II is the Vlingo voice functionality. Did you know (I ask because many people don't know) that if you tap the home button twice it brings up voice mode? The ability to recognize double clicks imposes a certain floor on the responsiveness of that button. That most certainly does bother me, and I've yet to discover how to disable it so it simply reacts immediately.

Why should it? The iPhone uses a home double-click to pull up the task manager/switcher interface. Yet single clicking the home button still instantly gives you the response you expect.

I get a consistent slight delay on the iPad. Nothing really long (maybe 500ms?) but if I pay attention I can definitly notice it.

Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy

#42

Post by Someone »

patrickgzill wrote: post #31
davesims wrote: post #6

“...a lot of the work we have to do today is because of certain choices made years ago... ...having the UI thread handle animations is the biggest problem...An easy solution would of course to create a new UI toolkit but there are many downsides to this also.” What would such a re-write look like, from a practical coding point-of-view? Couldn't this be done in a way that is transparent to the calling code, or would t…

That jumped out at me as well. I think there would definitely be a way to have most if not all of the underlying API calls set up to do this, without even needing to recompile the application.

If you move code that used to run (and was tested to) on the main thread to another thread, and run that thread in parallel with the main thread, you are creating a huge opportunity for race conditions.

Some applications may run fine, but I bet you will find a lot that do not, even ignoring timing differences that may cause problems with games.

Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy

#43

Post by charliesome »

code_duck wrote: post #18

I'd be interested to learn what the deal is with sound on Android. I'm a musician and love the software instruments on the iPhone/iPod touch... they're a joy to play. On my relatively modern Android phone (Motorola Droid 2), instruments are so laggy they are absolutely unplayable. A key press results in a sound up to half a second later, sometimes never. The response improved slightly with the upgrade to Gingerbread,…

This was on HN a couple of days ago and it turns out that it's down to the sizes of the sample buffers each OS allocates.

From what I understand, Android will only give an app a large buffer, so when the app starts filling up that buffed, it may take a little while for the 'playhead' (is there a more technical term?) to get around to playing those samples.

On iOS however, an app can request a much smaller sample buffer, so there's less lag time between when an app fills that buffer and when the samples actually get played.

Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy

#44

Post by rayiner »

This is almost certainly the right answer. Synchronization/priority is the #1 culprit when people complain that a UI is "laggy." It was why BeOS was so renowned for being snappy--all rendering was done in a separate high-priority thread. It's also one of the reasons Linux has always been criticized for a laggy UI: the X server/application/window manager triumvirate isn't so much slow as it is a total mess from a priority point of view. You end up needing priority-shifting schemes UNIX doesn't have (quickly shifting priority from the WM to the app to the X server as an event flows from the X server through the WM to the app).

Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy

#45

Post by untog »

randomdata wrote: post #36
ajross wrote: post #30

Earlier quoted context omitted.

"Proven itself" how, exactly? Last I checked Android devices were outselling iOS. Now, there's room for argument here about what the proper design is for a mobile OS. But if you're going to support your platform flamage with statements like "Consumers overwhelmingly demand" you need to synchronize the argument with the facts.

"Last I checked Android devices were outselling iOS." Source? There have been many reports of Android phones outselling the iPhone, but I am not familiar with the ones about Android devices outselling iOS devices (iPod touch, iPad, etc.)

Probably because that would be incredibly difficult to calculate. There isn't really an Android equivalent of an iPod, for a start. Do we include Nook and Kindle Fire devices in the figures? Because that would affect things.

At least cellphones is a more like-for-like comparison.

Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy

#46

Post by javert »

saurik wrote: post #10

"""It’s because on iOS all UI rendering occurs in a dedicated UI thread with real-time priority. On the other hand, Android follows the traditional PC model of rendering occurring on the main thread with normal priority.""" """On iOS when an app is installing from the app store and you put your finger on the screen, the installation instantly pauses until all rendering is finished.""" <- This is certainly not true. T…

has nothing to do with threading, and certainly has nothing to do with "real-time priority"

Well, it has everything to do with real-time priority, because in the case of Android, there is a clear priority inversion. That is, what should be considered the highest-priority work IMHO (updating the UI) is being delayed for other lower-priority work.

Absent other factors, the technically correct way of dealing with this kind of problem is using multiple threads and assigning the right OS priorities to them.

Maybe there are other constraints in iOS development that are causing the devs to wrestle with the main event loop instead.

Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy

#47

Post by vilya »

interlagos wrote: post #8

This isn't a "follow-up", per se. Nonetheless, while Android continually works to smooth out the rough edges -- helped along by the march of technology -- this is something that is a bit overblown: Minor jutters of the interface is something that primarily irritates people as a relative thing, not as an absolute thing. If you are a developer or a reviewer and you regularly use an iOS device and an Android device, the…

That directly contradicts my own experience with Android. I bought a HTC Hero as my first smartphone, so I didn't have any reference points to compare it with. Over 18 painful months of owning that phone I never got used to the lagginess of the UI. Not to the point where it faded into the background, anyway: I learnt to anticipate the lag, but it never stopped being annoying. So much so that when it came time to replace the phone, there was no way I was considering an Android phone again.

Basically, I'm an existence proof against your argument (and now a happy iPhone owner too).

Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy

#48

Post by untog »

andrewmunn wrote: post #4
sedev wrote: post #2

The takeaway for me is this: Android and iOS' creators made different tradeoffs in their UI programming. The iOS creators, overall, correctly predicted that a fast, smooth, responsive UI was something that users would care about enough that it was okay to pay a performance cost in other areas in order to make the UI as responsive as it is on iOS devices. Android's creators made a different tradeoff, and the UI on And…

This is correct. However, the Android team made their decision with the assumption that Android would power keyboard and trackball devices. That was never the case, so they made the wrong decision based on a faulty premise.

Android would power keyboard and trackball devices. That was never the case

Er, there are a lot of Android devices that are keyboard and trackball powered.

Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy

#49

Post by reidmain »

ajross wrote: post #30
illumin8 wrote: post #24

Earlier quoted context omitted.

The iOS decision was more correct because it has proven itself in the marketplace. Consumers overwhelmingly demand touch interfaces on their smartphones and tablets, as opposed to stylus, trackball, or any other that has come before it. Android started as a platform trying to out-Blackberry RIM. When the iPhone was released in 2007 they switched to a model of trying to out-do iOS.

"Proven itself" how, exactly? Last I checked Android devices were outselling iOS. Now, there's room for argument here about what the proper design is for a mobile OS. But if you're going to support your platform flamage with statements like "Consumers overwhelmingly demand" you need to synchronize the argument with the facts.

"Proven itself" can mean that iOS grosses more than Android. Last I checked iOS users spend more on apps/services than their Android counterparts.

Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy

#50

Post by saurik »

javert wrote: post #46
saurik wrote: post #10

"""It’s because on iOS all UI rendering occurs in a dedicated UI thread with real-time priority. On the other hand, Android follows the traditional PC model of rendering occurring on the main thread with normal priority.""" """On iOS when an app is installing from the app store and you put your finger on the screen, the installation instantly pauses until all rendering is finished.""" <- This is certainly not true. T…

has nothing to do with threading, and certainly has nothing to do with "real-time priority" Well, it has everything to do with real-time priority, because in the case of Android, there is a clear priority inversion. That is, what should be considered the highest-priority work IMHO (updating the UI) is being delayed for other lower-priority work. Absent other factors, the technically correct way of dealing with this k…

Yet on iOS, if you do silly work in the main/UI thread (which is very easy to do, as that really is your main thread on which you handle all events, and is thereby something many/most applications you find actually do quite often), it will block all UI updates for that process; claiming that iOS is solving UI lag by having a dedicated UI thread that is marked "real-time priority" is, AFAIK, wrong.

In fact, it is this very property (that on iOS, all UI work must be done from the main thread) that often /causes/ UI lag, and yet somehow Android (where even this author admits using background threads for non-UI work "is the standard Android design pattern" in one of the comments on his post) is the one with the serious UI lag issues <- this mental contradiction is the key problem, and it would be awesome if someone (from Google or wherever) provides a strong explanation.

Post reply on HN