Follow up to “Android graphics true facts”, or The Reason Android is Laggy
1–10 of 118 posts
Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy
#2The 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 Android devices showed clearly - and continues to show - the problems with that tradeoff.
Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy
#3I don't know if his technical explanation is correct or not, but he is absolutely right about the importance of responsiveness. I was an Android early adopter (G1) and while I could put up with slower HTML rendering (for example), I could not tolerate the poor responsiveness.
Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy
#4The 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.
Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy
#5The 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 designed iOS to make rendering in a special, real-time priority thread to ensure responsiveness.
Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy
#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 there have to be a fundamental re-write of the SDK, i.e., the UI thread no longer be the main thread?
Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy
#7The 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…
The interesting thing would be an estimate of the amount of work needed to move the android ui-rendering to its separate real-time thread. Would it even be realistically possible?
Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy
#8This 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 difference is evident and jarring. If you're an end-use it quickly disappears and is a non-issue. It just isn't a real problem for end users.
It's the same as getting an upgrade to your PC, a new video card, etc. You were perfectly happy before, but relative to your new reality the old one seems subpar, and you overestimate how much it interferes with your enjoyment of the device.
Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy
#9Finally an answer and seems like a reasonable one. For a time I had both a Nexus One and iPhone 3GS. The Nexus One was faster in just about about everything, but using it just felt like work. The iPhone comparatively was a pleasure to use.
Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy
#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. The update of the display for the installation progress might (...might) stop, as that's happening in the UI (aka, "main") thread of SpringBoard (and the event loop management might ignore incoming events that are not related to the touch event until after the gesture completes), but the installation itself is being managed by a background daemon (installd) and will not stop because someone is touching the screen. The operating system is /not/ doing something hilariously insane here, throwing out all computation on the device because someone is accidentally touching it.