Meanwhile, at Apple, they would have got it right in version 0.1, and Steve Jobs would treated that as prototype quality and made the team do 10 better variations.
Meanwhile, the current generation of dual core Android phones have hardly any lag issues anymore.
So... laggy sometimes, but still smooth scrolling.
Every Android device I've tried (just tried a couple tablets at a Best Buy this week) have been consistently laggy (response times to swipes) and choppy scrolling.
Just FYI.
Garbage collection has never had anything to do with poor UI performances, and everything to do with making poor code stutter. When the GC starts hitting your framerate, it means you are creating far too many objects and far too frequently. Before ICS, android implemented the incremental GC that runs more often but for "negligible" sub-1ms lengths.
If you absolutely need 60fps, make sure the GC never gets to do any work and start monitoring your own memory through buffers, just like you would in any other language.
Garbage Collection very slow on Android with latest stable line http://groups.google.com/group/v8-users/browse_thread/thread...
How can I avoid garbage collection delays in Java games http://stackoverflow.com/questions/2484079/how-can-i-avoid-g...
Avoiding garbage collection for smooth 2d animations Options
http://groups.google.com/group/android-developers/browse_thr...
Image tiling on Android, garbage collector slows down http://stackoverflow.com/questions/7916021/image-tiling-on-a...
Nothing beats primitives and buffers - the performance gap between the two methods is huge, that's true, but it's not a showstopper.
I don't recall gcs in other processes hurting my apps performances though. With that said, if I'm going to write a game, I'll make sure none of the threads in my process will trigger a GC past the loading/splash screen. This means no instanciations of any additional iterators, collections, Strings... The overhead of allocations is almost as bad for the framerate as the GC anyway.
I can barely stand the, in my opinion, horrible mouse acceleration in OS X and knowing apple I can imagine that they feel that giving me the option to disable it isn't user friendly.
Am I the only person in the world for whom the inertia of a scrollable area at rest, tending to stay at rest _is_ what feels right?
Android's Webview unfortunately requires a rewrite from scratch. It just doesn't work as soon as the webview is more than a static page. Css Animations don't play anywhere near fast enough, there are furious hardware acceleration glitches whenever the touch keyboard pops up, touch events are slow as hell, etc.
The article only touches the surface of the problems with the Webview component. At this point we don't care about scrolling. since one pretty much has to hack a custom Webview component just to avoid all the hardware glitches, display artifacts, buggy input handling, terrifying variations of performance from device to device...
Two exceptions: Audio latency. It is impossible to write certain classes of table applications for Android right now, because no priority was given to having a low-latency audio subsystem. Its at least as big a mess as display acceleration.
I don't know the technical details (though I'd assume hardware acceleration is a big deal), but evidently Apple can achieve a good user experience while consuming far less resources. It's taken Android years, and I probably have to buy a new device.
I also develop some of the biggest apps on both platforms and know more about their internals than I'd like.
I'm replying to this: "It has a much higher resolution than iPhone 3GS. In fact, it has six times more pixels." That has zero to do with the article.
There's nothing in my answer that's incorrect. Sure, your Galaxy Nexus can now sort of scroll reasonably smoothly (the one on my desk is okay, but still lags). But that's because of the GPU which is something like 6x faster than the GPU in a 3GS. And the fast dual core CPU helps, too.
That doesn't mean that Android hasn't come a long way in ICS. But it'll never catch up to iOS in terms of rendering performance/latency. It's an impossibility due to the underlying architecture.
> That's irrelevant, since the GPU does all the heavy lifting.
The article: "There is still a limit to how much the GPU can do." (And the rest of that paragraph.)
Yes, having 6 times more pixes is very relevant. The GPU needs to be 6 times faster and have 6 times the bandwidth.
> I'm replying to this: "It has a much higher resolution than iPhone 3GS. In fact, it has six times more pixels." That has zero to do with the article.
Conclusion: You did not read the article - you just skimmed the first paragraph.
They ultimately, however, don’t matter†. If scrolling on one device makes me want to throw the device at the wall while on another device I don’t even notice that I’m scrolling, then that’s a problem.
I’m looking forward to trying out an Android 4.0 device to see whether I still want to throw it at the wall. That’s the only thing that matters to me. (Lagging is only part of the problem and occasional lagging really isn’t a problem. What always annoyed me much more was the delayed reaction. I swipe, nothing happens, the page scrolls. That’s extremely annoying.)
—
† They obviously do matter. Different implementations lead to different results. But only talking about the implementation and ignoring the results misses the point.