[Verizon Droid Charge] ambrar12:
I don't think this is a fair argument. iOS multitasking is just done differently and has a scheduler optimized for mobile devices with battery constraints. However it is no doubt more limited, which is why I used Meego as an example. Meego has true multitasking, but is still extremely responsive to input with an extremely smooth UI. Even incomplete webOS is more responsive in the browser (although not smooth). And multitasking isn't the only issue with Android.

Take one of the poster's comments: "While the S2's browser is fantastic, other parts are not - such as an SMS inbox with a thread of 30 or so messages, or scrolling through a long list of contacts (it seems to 'stutter' when the ListView has to render headings while scrolling is occurring, so it's not 'fluid'). Third party apps suffer the same fate (i.e. IMDB: scrolling through 'Latest Trailers' or the 'Coming Soon' list, same app on iPhone - buttery smooth and flawless fluidity which makes the end-user feel good).

...

Or Skype: install Skype, chat with someone, then scroll up the chat. I'm not even going to start on viewing/panning around PDF files ;(."

Another poster with a custom kernel claimed smooth experience on a different app with similar functionality, but that speaks to xda's accomplishments, and not to Android's effectiveness.

Jay Freeman (aka Saurik... I had no idea) sums up the above mentioned issue here:

"http://news.ycombinator.com/item?id=3332357 <- check out the responses from Xuzz and ryanpetrich.

In particular, iOS in fact has a multi-window architecture: applications can be made up of multiple UIWindows, and you can have UIWindows from different processes on screen at the same time. When you click on applications in SpringBoard, the transitions you see are animations of windows, and it would not at all be difficult to implement (from a rendering perspective) a scheme where different processes registered something similar to Android's activities, where clicking links slid one process's content off-screen while sliding another process's content on, even while sharing a navigation bar.

The status bar actually used to be an example of this, but they changed it at some point (and honestly I do not remember why, but I do not believe it to have been due to a rendering issue); the notification center, however, is a good current example: the window for the notification center is in SpringBoard, but it is rendering over and at the same time as the window for the application you are covering. There is also no issue having these windows alpha composite onto each other: the little popups that happen from clicking the volume buttons are windows in SpringBoard.

The reason for this is that, like with most multi-window environments (including Android), there is a window manager that is handling all of the actual compositing. In this case, it is SpringBoard, the process that manages the home screen, task switcher, notification center, lock screen, and honestly almost anything that has to be "always happening". The way this works is that surfaces (backed by system or video memory) are managed by a driver that allows them to be passed between processes: applications can render directly to their surfaces, while the actual surface hierarchy is maintained by SpringBoard.

Honestly, though: around here is where my knowledge is really fuzzy, and can't be trusted; Ryan Petrich's knowledge can be, so I will quote his comment from Hacker News: """On iOS, all standard rendering is done in a single context by the Core Animation window server which lives in SpringBoard. Only when an app adds an OpenGL ES layer to the view hierarchy does a separate context need to be created. When that happens, the render graph is split into subgraphs that are rendered to surfaces and displayed as overlays (with SpringBoard rendering all the standard layers and the app rendering the OpenGL layer)""".

The result of all this is that your comments regarding iOS's inability to handle multiple applications sharing screen real-estate in an efficient and secure manner are simply false: the fact that Apple does not support the Android notion of seamlessly moving between applications, with a back-button instead of simply an up/home-button, is simply an irritating business decision they make. As mentioned by Xuzz on Hacker News, it would be a simple manner to, for example, modify UIKeyboard to be handled by a separate process from the app that was calling for it: the involved work would not be rendering complexity.

Finally, the reason why you need to be careful with your view hierarchy to get 60fps scrolling is due to the complexity of loading new table cells and rendering them for the first time: once they are rendered they scroll quickly as the entire layer is cached (afaik, and if I'm wrong on this it doesn't actually matter). The problem on Android is that, even in the best possible cases, where you are staring at a trivial table implemented by the Android team itself (such as the Settings/Preferences app), there is noticeable UI latency and slop while moving your finger over the screen. When you read threads like the response to your first article on Hacker News, you can see this is a serious challenge for Android."

Dianne Hackborne's response is to disregard these points by claiming all of this is due to the nature of GPUs on old Android devices: "Unfortunately for us, until recently we just didn't have GPUs that could do multiple contexts, so if our system worked like that we wouldn't have been able to ship. :}"

She uses the Nexus S as an example of a "newer" device that solved these problems: "For example, a Nexus S can definitely does 60fps on well written lists."

Sadly, my Droid Charge still stutters on lists and when opening the app drawer.

Jay refutes her silly claims and cites an article on lag in ICS on the GNex and lambasts her for attempting to spread the false claim that Android's lag is due to sandboxing and security issues. I've even seen Hackborne (or at least someone claiming to be her) posting on sites like ArsTechnica with various long-winded arguments like the one she posted on Google+. It's bizarre how unwilling she is to directly address these complaints.

Sorry for the long post. It's a wonderful thread with plenty of amazing back and forth arguments. I just want Google to recognize the issues and talk about them more in public. Talk about how they're specifically addressing them. I'm excited as the next guy to get ICS, but it's just not enough. I've seen videos comparing browsing in ICS compared to a single-core A8 WP7 phone. Scrolling and zooming... just no comparison. As much as I hate to admit it, the idea of an HTC Titan II with 4.7" screen and LTE makes me jealous. What I wouldn't give to have an Android phone with that kind of user experience.