21–30 of 109 posts
Not to be a jerk... But this still doesn't address why every Android home screen I've seen (including new 4.0 devices) looks like a laggy piece of shit when sliding around between different screens.
[offtopic] Isn't saying "true fact" redundant? Unless it's true , how can it be a fact ? [/offtopic]
Android's graphics problems are not due to a lack of hardware acceleration. They're due to poor architecture. The reason iOS is so silky smooth is because each view in UIKit is backed by a CoreAnimation layer which will be a pixel buffer in hardware. This means that if you move a UIView in iOS, no new rendering needs to be done of stuff that was "uncovered" by moving the view since each UIView has the full contents o…
Did a bit of investigating. It seems you can make Android views use layers as iOS does. But it's off by default (maybe because of this OpenGL using 8MB of memory per process thing). (Further reading: http://developer.android.com/reference/android/view/View.htm... ) Edit: Also, I missed where she said that in her post: "Starting with 3.0, if you set the flag in your app saying that hardware accelerated drawing is allo…
Google suggests toggling between LAYER_TYPE_NONE & LAYER_TYPE_HARDWARE pre/post animations. This need to actively manage view cache behaviour probably leads to developers being unaware of what to do.
http://www.google.com/events/io/2011/sessions/accelerated-an...
Those are some nice technical details and it’s right to correct them when someone gets them wrong. 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…
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.
Those are some nice technical details and it’s right to correct them when someone gets them wrong. 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…
So I'm guessing that the reason iOS home screen scrolling is faster is because it has much fewer things to draw?
I wonder if it has anything to do with the Delegate pattern used in iOS vs Android's Listener pattern when it comes to handling continuous touch events on the main thread, rather than the rendering speed.
Earlier quoted context omitted.
Did a bit of investigating. It seems you can make Android views use layers as iOS does. But it's off by default (maybe because of this OpenGL using 8MB of memory per process thing). (Further reading: http://developer.android.com/reference/android/view/View.htm... ) Edit: Also, I missed where she said that in her post: "Starting with 3.0, if you set the flag in your app saying that hardware accelerated drawing is allo…
Turning on hardware acceleration doesn't cause all Android views to be FBO-backed. You still need to toggle the layerType to LAYER_TYPE_HARDWARE on each view, as far as I'm aware. I think the G+ post is a little disingenuous in that regard. Google suggests toggling between LAYER_TYPE_NONE & LAYER_TYPE_HARDWARE pre/post animations. This need to actively manage view cache behaviour probably leads to developers being un…
LAYER_TYPE_HARDWARE enables smooth hardware-backed scrolling but glitches badly when the soft keyboard is visible (no resizing/panning of the webview, multiple seconds of delay between key type and text updates inside textfield forms).
LAYER_TYPE_NONE makes scrolling in the webview unbearably stuttering, but at least the soft keyboard becomes responsive, the webview pans correctly to show the field in which you're inputting text, and the key types are instant.
On top of that, there is the problem that you don't have access to keyboard show/dismiss events, so you have to inject javascript code to catch those in every page you plan your webview to display. This is at least the case on the Motorola Xoom and the Acer Iconia tablets running the latest versions of honeycomb.
Those are some nice technical details and it’s right to correct them when someone gets them wrong. 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…
It blows my mind that people can't understand that scrolling "feels right" is a show-stopper feature for a touch interface. 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.
It appears to me that this article is trying a little bit too hard to paper over the poor UI performance of Android compared to iOS or WP7, and making up excuses for less than optimal drawing performance. It doesn't say _why_ GPU rendering isn't much faster than CPU rendering on Android, it doesn't say why using OpenGL adds 8 MB to the RAM overhead to a process (something I can hardly believe by the way), it glosses…
I'm surprised that many people are still bashing UI responsiveness/performance. I've held and played with many devices (including, but not limited to, iphone 3 and 4) and I can't really say what's bothering so many people. For me, every android device that I've used in the last 2 years feels fast and responsive. I'll just go out and say that it's a non-issue for mainstream user.