How about some Android graphics true facts?

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 over the fact that even though you _could_ render some things at 60 fps using just the CPU, that still means these CPU cycles can't be used for anything else, it doesn't mention the fact that GPU rendering is almost always more power-efficient than CPU rendering, and it doesn't differentiate at all between _what_ can efficiently be rendered by the Android hardware rendering and _how_, besides making the distinction between compositing and 'rendering in a window'.

The final comment about memory bandwidth also makes little sense when talking about CPU rendering vs GPU rendering. Most mobile GPU's use some form of tile-based deferred rendering that allows the use of dedicated on-chip local buffers and efficient caching, to greatly reduce RAM bandwidth pressure. If anything suffers from constrained RAM bandwidth, it's CPU rendering.

From a technical perspective this article is a very naive analysis, at best.

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.

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 of its view stored in its CALayer. All that needs to happen is all of the layers are composited in their new positions which hardware will blazingly fast. However, as I understand it in Android, each Window (containing multiple Views) is one pixel buffer in hardware. Each view then draws in to that. This means that if you move a View in android, another view will be "uncovered" and since that area of the screen isn't stored somewhere, it has to go down the view tree rendering the now uncovered area of the screen. Even if that rendering is hardware accelerated, it's still going to be muuuuuch more work that just recompositing all the layers on the screen as in iOS, I mean imagine if there's text uncovered there? That's not going to be quick.

Now, there are downsides to iOS's approach - it uses a bunch more memory. But the upsides are basically what makes iOS good - all those silky animations. Android's just getting to a similar level of smoothness, but mostly only through better hardware.

(Caveat: How android works may have changed since I last looked, but that just makes the mystery of lack of smoothness even more interesting ;-) )

Doesn't this make Android look even worse? I.e., "Android already has hardware acceleration but still doesn't seem to perform very well" means any hope of flipping some magical GPU acceleration switch and instantly fixing the problem is gone.

I don't use any apple products but I get tired of Google touting how much better 4.0 is when most people are locked into phones running 2.2 or 2.3 for years into the future.

There is still a limit to how much the GPU can do. A recent interesting example of this is tablets built with Tegra 2 -- that GPU can touch every pixel of a 1024x800 screen about 2.5 times at 60fps. Now consider the Android 3.0 tablet home screen where you are switching to the all apps list: you need to draw the background (1x all pixels), then the layer of shortcuts and widgets (let’s be nice and say this is .5x all pixels), then the black background of all apps (1x all pixels), and the icons and labels of all apps (.5x all pixels). We’ve already blown our per-pixel budget, and we haven’t even composited the separate windows to the final display yet.

I find this bizarre. Are all of these drawing operations using alpha blending (using translucency)? If so: is that strictly necessary for the entire area of all of them?

If they aren't using blending, why on earth do they have so much overdraw? The GPU could reduce that to touching each pixel exactly once by using the Z buffer and drawing in front-to-back order.

Just put any newest and fastest Android phone with dual-core CPU next to iPhone, or even worse WP7 which essentially works on two years old hardware, and everyone can see the difference. I don't care if it's software or hardware, I'm not interested in excuses about the work in the GUI thread. What I'm care is - the phone is something I touch. If I don't have immediate response to my gestures, the device is useless to me. As simple as that.

This is not only a bad experience for users but also is one of the most difficult parts when developing Android apps.

http://www.google.com/events/io/2011/sessions/accelerated-an...

I can understand why Andoid would have theirs set as they do, but I also understand how someone used to iOS could find it unpleasant.

It's all just software. The only thing that matters is how fast it is.