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

11–20 of 118 posts

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

#11

Post by interlagos »

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…

How was the iOS decision more "correct"? Android is clearly succeeding despite the lack of UI refinement, so it's hard to hold one as victorious.

There is definitely a different philosophy, though. The Android approach was that it was better to be correct -- if you scroll a page or a webpage, that what scrolls into the viewport needs to be correct, while iOS happily scrolled in a checkerboard. I prefer the stock Android approach (some devices, such as the GS II, sub in the "better to be fast" approach, giving smoother superficial interactivity) so long as there is enough hardware that the result isn't too painful.

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

#12

Post by wvenable »

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…

Apple is also willing to put a lot of burden on the developers. Having a separate UI thread is more difficult than doing all rendering in the main application thread. Supporting only native code without garbage collection is also more difficult on developers too.

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

#13

Post by YooLi »

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.

I don't know about saying "That was never the case...". At the time the decision was made, a blackberry-style device was indeed the target. The problem was when the target shifted to iPhone instead.

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

#14

Post by MichaelGG »

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…

Not quite. For instance, on a Galaxy S II, going to the home screen while in the mail app takes ~2 seconds. Doesn't matter how many times I do it, or even if I just do it in a loop, switching between mail and home. It's probably not even Android's direct fault - I wouldn't be surprised if this is Samsung's horrible software shining through - but it's very frustrating, and I don't use other devices to compare it to.

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

#15

Post by interlagos »

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

Not quite. For instance, on a Galaxy S II, going to the home screen while in the mail app takes ~2 seconds. Doesn't matter how many times I do it, or even if I just do it in a loop, switching between mail and home. It's probably not even Android's direct fault - I wouldn't be surprised if this is Samsung's horrible software shining through - but it's very frustrating, and I don't use other devices to compare it to.

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.

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

#16

Post by illumin8 »

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…

+1 I think this Saurik guy knows what he's talking about... Now where have I heard that name before? (hint his software runs on over 2 million devices)

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

#17

Post by illumin8 »

interlagos wrote: post #15
MichaelGG wrote: post #14

Earlier quoted context omitted.

Not quite. For instance, on a Galaxy S II, going to the home screen while in the mail app takes ~2 seconds. Doesn't matter how many times I do it, or even if I just do it in a loop, switching between mail and home. It's probably not even Android's direct fault - I wouldn't be surprised if this is Samsung's horrible software shining through - but it's very frustrating, and I don't use other devices to compare it to.

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.

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

#18

Post by code_duck »

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, but not enough. iOS instruments are responsive enough you could play them in concert if desired... on the other hand, I can't even entertain myself with the Android music apps.

Is this just the difference between Java and Obj. C?

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

#19

Post by jcizzle »

Pretty close on the iOS stuff:

1. All* rendering takes place on the main thread in iOS.

2. The main thread doesn't always have the highest priority. In fact, its priority level changes throughout an application.

3. There is more than just one reason iOS rendering is so fast. Here are two important ones:

a. Animation is actually the basis of the entire rendering system. On desktop Cocoa, the drawing system was a little dated. The mistakes learned from this system and the desire to have fast animation led to the Core Animation framework and the idea of "layers". The ability to quickly composite layers (without moving any data from between the CPU and GPU) and only redraw when necessary is huge.

b. The batching together of drawing updates at the end of an event instead of on an as needed basis allows for huge performance gains.

* It is possible to draw in a background thread, but is reserved for particular situations (maps, web content, etc.). Table views do not fall into this category.

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

#20

Post by yardie »

daniel_solano wrote: post #5
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…

I think it the takeaway is slightly different: When many of Android's fundamental design decisions were made, specifically making UI animations take place in a normally-scheduled application thread, the prime competition/inspiration was the keyboard- and trackpad-driven interfaces of competitors such as Blackberry. Apple, on the other hand, decided that a touch-based interface was the way to go. As such, Apple design…

If this is true than it blows a hole in the assumption that Android was designed with a touchscreen in mind.
Post reply on HN