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 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.
>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.
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.
"I'll just go out and say that it's a non-issue for mainstream user."
Might also be why the "mainstream" is primarily using Apple iPads/iPods/iPhones vs the myriad of Android devices available.
What bothers people is that when you swipe from screen 1 to screen 2, there can be a > .5 second delay. It doesn't feel remotely "natural" for something that you're physically touching and supposedly interacting with.
The mainstream who shop at stores where every single appliance/device has "works with your iPod/iPhone!". The mainstream who go to hotels that have iPod docking stations in the room alarm clocks. The mainstream who go to fitness gyms that have iPod/iPhone docking stations in the workout equipment.
Ah, but you are conflating UI performance with something else. My point is, that UI performance is not an issue (at least hasn't been for a while). Other things, like high quality apps, ubiquitous docking stations in cars/hotels/..., on the other hand are quite important. That is, for vast majority of users, geeks who type 40+ words/minute on miniature screens don't count.
My position is that "mainstream" users - the type of people who care about the apps, docking stations, ubiquity of the platform, etc - also care about UI fluidity.
Look again, because iOS has greater market share than Android does. But it's a moot point anyways, because one OS is limited to a few devices that sell at high price points and the other is used by tens of manufacturers and hit low, medium, and high price points. Actually, because of that, it makes iOS's market share even more impressive.
What did I say that was wrong? The guy had the idea that Android has greater market share than iOS, I stated my belief that he was wrong, and then I got downvoted. Some of you guys are too trigger happy with your downvoting buttons. If you're going to downvote, at least explain why so everyone is wiser in the end.
I think people probably want you to cite some sources for what you're saying. Because pretty much every article I've read says that Android has a significantly larger market share:
Ahh, that's a good point. I usually like to leave others to google it up, but I guess it really is stupid for me to not put a source down since then I could just be making things up.
I may be mistaken for what these stats show, since things are very confusing with Android vs iOS. Some places claim one way and other places claim the other. I think the ones that claim iOS have a larger share are counting iPhones, iPod Touches, and iPads. Here's two sources that show iOS having greater share:
The second one (not sure about the first) is getting their stats from web hits, so how accurate it is, I do not know. I think aside from Apple and Google, no one really knows the real market share.
This is now 3 sources claiming iOS has greater share than Android, and even if they are a bit outdated, it's proof that the 60% share vs 15% share cited in many articles refers only to the phone wars (most articles I've seen eventually mentions the words "smartphone").
There is no real confusion, except what you seem to be trying to create.
The BRG report is using one companies analytics product (which is embedded in apps). Plainly that is more popular on iOS than Android, but we've seen that before - most people on Android use Google Analytics, so 3rd party analytics aren't reliable when comparing them.
The Statcounter stats clearly show Android and iOS are within a couple of percent (note how Android was above iOS a month or two ago). Given that the iPAd is the most popular tablet on the market (and people browse the web on tablets a lot more than on phones) this makes it even more likely that Android is ahead in units.
Your stats refer to smartphones only whereas mine specifically says iPod touches, ipads, and iPhones. Given that the company doing the research is the same in both, but the labels are different, this difference could hold significance. Furthermore, if your table actually means what it's supposed to, it would mean android went from 10% share in February to 42% share in June.
Also, there are many factors at play as any Stats student knows. Simply making assertions that android users are misrepresented could be dangerous.
>Might also be why the "mainstream" is primarily using Apple iPads/iPods/iPhones
I don't believe the reason for that is UI responsiveness (also, I don't agree with your 'primarily' assessment, but let's not chew on that). In my opinion, the differences are so small that UI performance just isn't an issue. There are other areas where iDevices are noticeably better compared to every competing device.
>What bothers people is that when you swipe from screen 1 to screen 2, there can be a > .5 second delay
Hm, I don't remember that ever happening to me in the last ~2 years with two devices that I've used most: nexus one and motorola defy. But ok, I grant you that it can happen. So what? I've also seen an iPhone freeze completely.
For me, the UI performance is the single biggest reason why I don't use Android as my primary phone. No matter how fast the underlying action is, the jumpiness and occasional lagginess makes it feel slow to me.
It frustrates me - there's so much I like about the OS that so many good things can be erased by leaving the visible perception of being slow.
Hm, I don't remember that ever happening to me in the last ~2 years with two devices that I've used most: nexus one and motorola defy. But ok, I grant you that it can happen. So what? I've also seen an iPhone freeze completely.
That's funny. I use a Nexus S on a daily basis, and compared to my primary phones I've used over the last 3 years (iPhone 3GS, 4, and now 4S), the touch screen is awful.
The incontrovertible truth is that every mainstream Android device on the market, including the newest SGS2's, have this annoying 500ms/20 pixel touchscreen 'slop'. And it's annoying as hell. It makes the touchscreen and all the widgets feel slippery. It ruins the built-in android keyboard (I can type at 40+ words per minute on the ios5 touchscreen keyboard, and I need swiftkey if I want to type that fast on android).
Ignore this all you like. Those of us who want something better know where to get it.
But you're forgetting the other big screen criteria people have: "not from Apple". Once you factor that in, the Android platforms all fare much better. :)
This has got to be mostly a perception problem, because it's all I ever notice when using any Android device. Swipe/scroll lag has always been noticeable for me. And yes, iPhones do crash/break/jitter, but it's by far a very small percentage of the time compared to how often they're used.
As for a "reason" for people using Android: most of the people I know who use Android-based devices have "It's not Apple" as one of the top few reasons for using it.
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 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.
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.
Apple makes compromises, too. On the original iPad scrolling can be really laggy (probably only after installing a couple of apps, so you won't notice it in the store).
Meanwhile, the current generation of dual core Android phones have hardly any lag issues anymore.
Somewhat agreed. It can be laggy, but on mine it rarely is (but it does happen). However, it's never consistently choppy when scrolling.
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.
Yes, because the scrolling is very well supported by hardware. But you will notice the slowness when you are zooming in/out of pages (the font smoothing takes about half a second). But Apple got it right compared to Android, and you are right that even today the iPad holds up well, considering its hardware (reminds me of the C64 which was able to smoothscroll because of hardware support, while the PC didn't manage it at that time)
I think he means the number of apps running in the background. For example, if you have the Groupon app making constant push notifications to you, that's expensive.
Garbage collection in Android is another performance bottleneck. ICS "fixes" this by allowing the garbage collector to run on a different thread but imo that's
a kludge.
You're beating a dead horse alright, but it's the wrong one.
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.
Users don't distinguish between poor UI performance and"code stutters". The "negligble" sub-1ms stutters are a real problem in practice. and it's not just limited to poor code. Sometimes, no matter what you'll see GC being called, there's no way around it. There are background threads that are doing all sorts of things, which very well might be getting GC'd. Theres also a lot of things you can't
reasonably avoid, like allocations from Iterators, etc. There are literally thousands of forum and blog posts discussing this online.
Poor choice of words on my part. It's not "poor code" but "inadequate code". The Android graphics API is, overall, inadequate for avoiding GCs at all costs. Java on the other hand, is not necessarily inadequate. The issues with GC and the Bitmap class are a good example: Bitmaps aren't designed to work at the lowest & fastest level but at the highest and easiest level.
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.
It's a definitional thing. "Works" at (say) Microsoft or Google means "produces a correct result at the end" whereas it means something quite different at Apple. The most egregious example I've seen of this is the way Mac OS filtered mouse movement data from the beginning, but it still doesn't feel right on Windows (and wasn't even in the ballpark until around Windows 98/NT4). (And, by contrast, the Amiga had pretty much nailed mouse movement early on as well.)
You say that as if that was a fact but in reality is nothing but your opinion.
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.
Yes, the Mac acceleration is horrible. The best solution I've found is to buy a Microsoft mouse and install the Microsoft driver for it. Works properly, just like Windows.
All the windows phone 7 devices I have seen work extremely well in terms of smooth scrolling. Definitely on the same levels as ios devices if not better.
I've had the chance to enjoy dual-core android phones (Atrix, 2.2) & tablets (Xoom, 3.1). The difference compared to single-cores is gigantic, everything is super smooth, on the level of the iPhone/iPad as far as responsiveness goes for apps and home screen. I have to say that if the goal is to have a superb OS given a powerful enough phone, the goal has been met, with one (critical!) exception:
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...
> OS given a powerful enough phone, the goal has been met, with one (critical!) exception
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.
Any Android users out there that want to see Android succeed should star the issue linked in the parent comment. There are a significant number of excellent music/audio apps for musicians and tinkerers for iOS that are not possible on Android because of the above issue. For example, search YouTube for "EveryDay Looper".
I have also played with and had dual core android phones and the scrolling experience is nothing like iOS by any means. One of Steve Jobs skills is that he had an innate feel for good scrolling well beyond the feel of the average person. It might feel the same to you. You might be perfectly happy with an android. Still, android has a challenge to make the OS feel as snappy on a wider range of CPUs and platforms than iOS and the lack of of consistency, even on dual core machines is like night and day.
Meanwhile, I have a phone with nearly identical specs to the iPhone 3GS (a Motorola Milestone), and it "feels" slower than my first-gen iPod touch, which manages to do beautifully smooth scrolling with really wimpy hardware.
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.
Yes, I did. It's full of excuses for sub-par up front planning on the part of the Android team (much like the reliance on SD storage early on -- LOL at that bit of idiocy. I still see emails from people complaining that the on disk size of an app is a whole 3 megabytes. Mean while, in iOS land, Infinity Blade 2 is 800 Mb).
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.
You must realize nothing Google does to Android can fix a crappy phone. But, since Android is open-source, the manufacturer itself can change it and fix their problem. If they are nice enough, they may even submit the patch back to Google so similarly poor designs can benefit from it.
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 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 ;-) )
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).
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 allowed, then all drawing to the application’s windows will be done with the GPU. The main change in this regard in Android 4.0 is that now apps that are explicitly targeting 4.0 or higher will have acceleration enabled by default".
Unfortunately only the the Samsung Galaxy Nexus has Android 4 and I'm not sure there's anything other than a few tablets that have Android 3?
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 unaware of what to do.
If you want to enjoy both smooth scrolling and responsive input method in a webview, you need to juggle between those layer types.
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.
There must be a different underlying issue there. Showing a keyboard view should have no performance implications on a web view. Similarly drawing text into a texture tile should not take "multiple seconds of delay".
Is this a defense for Android's poor responsiveness (often blamed on a lack of hardware acceleration), or is there some other context I'm missing?
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.
The context is a bunch of people going around pretending they know why Android behaves the way it does, when in fact they have no clue what they're talking about. It's not a defense of anything, it's just injecting facts where there has been a distinct lack of them.
So, in summary, "We have hardware acceleration, have had it for a long time, but it isn't the reason android interfaces are almost universally clunky. We actually have no idea why that is."
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.
If I hadn't had a family member willing to give up their upgrade for me, I would be locked into a phone running 1.6 until May 2012, one which has no custom ROMs.
The non-smoothness of android interfaces is a gigantic hulking monstrosity of an issue. I deal with it dozens of times a day, and have been for years now on multiple phones. It is the sole reason why anyone cares whether android does hardware or software graphics acceleration. No one would care if there wasn't a problem for which they picked software acceleration as a cause.
The post spends pages on how hardware acceleration in android is just fine, but it completely ignores the actual problem. This is like a man in court for a DUI who bases his whole defense around the fact that he has a legitimate driver's license.
Going from Heinlein's razor, I assume that google does not know the cause of the problem. The alternative is that google is deliberately trying to mislead us by ensconcing the clunkiness issue within the hardware acceleration issue in the belief that by disproving the software acceleration claims they can nullify the elephant in the room: poor user interface performance.
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.
I thought you raised an interesting point and posted your comment over there. Romain Guy answered : 99% of the drawing operations performed by the UI involve alpha blending. We have optimizations of our own to limit overdraw (for instance layers generate meshes to avoid blending completely transparent fragments). So there's overdraw, just not as much h nS
Indeed. I wrote the graphics motor for a set top. I'd last year, and that is one of the many optimisations the weak hardware required to make UI animations run smoothly. It's hard to believe that Android doesn't do this.
I'm really, really sick of hearing Google engineers saying that there's nothing wrong with Android rendering. No offense, but post like this one makes them looks like idiots.
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.
You seem to have read a much different post than I did. Where did she say there's nothing wrong?
The post is relating facts about "how graphics rendering works on Android", it says so right at the top. I see absolutely nowhere that it says anything like "there's nothing wrong".
It seems that when you've decided what the article says before you read it, it makes forming opinions (and avoiding cognitive dissonance with respect to your existing ones) a lot easier.
I believe it's meant to be ironic, in other words taking a poke at the so called "facts" that people generally toss around (although that doesn't make it less annoying).
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.
i think this is probably the most accurate thing that can be said. thank you for posting this, do you think the linux scheduler subtleties / server-process-optimization may add to this?
I'm afraid I have absolutely no knowledge of these. I'm more of a high-level self-taught app dev, things that happen under the hood go far above my head most of the time :)
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.
How can you say "4.0 devices" (plural) when there is only one announced 4.0 device, which is stunningly smooth in the video and in actual use?
I think you're just repeating the meme of "lol Android graphics are bad" which hasn't been true for at least 2 years, even with relatively weak phones (like the Optimus X)
Works fine on my year-old Desire HD, even with hardware acceleration not supported yet on the ICS ROM. It's all very smooth. Hell, even 2.3 runs great.
On my hideously slow Galaxy 3, which barely runs Angry Birds, I can successfully do the most complex home-screen transitions smooth as butter with LauncherPro.
I seem to recall hearing that one of the main drivers of people's preferences for Android or iOS scrolling is how far you have to move your finger before scrolling starts. The delay in space, rather than in time.
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.
My point is, software is rendering the graphics. Either it's software running on one chip, or it's software on another chip. That's irrelevant. What matters, is how fast the graphics are rendered.
I'm not downvoting you, but you're implying that the difference between hardware and software rendering is irrelevant which it certainly is not.
What's interesting is not only how fast the graphics are rendered, but the graphics performance compared to power usage. If the software stack doesn't give you a big performance / watt advantage when using a GPU, that's the fault of the software stack and will make that stack perform worse compared to one that does make use of hardware acceleration.
Software rendering means that it's handled detail by detail by software on a general-purpose computation device.
Hardware rendering means that the software instead initiates complex actions on swaths of the screen at a time by triggering highly-specialized hardware.
One method is orders of magnitude faster than the other, but limited in scope. It's a fool's errand to try to conflate them.
Maybe you, as a consumer, only care about how fast something is. This post is more geared towards people who actually care about how things work, or, more pertinently, to the people who have been spreading misinformation around. So it isn't a post about Android's being slow or fast as much as a post about its internals.
There is a big difference between hardware and software rendering. Software rendering has you plotting each pixel individually and writing to the framebuffer. Hardware rendering uses specialized APIs and hardware to dramatically speed up drawing and transformation functions.
Indeed, Apple's Mac OS X QuartzGL framework (GPU accelerated drawing/rasterisation) is slower than the equivalent CPU-based Quartz framework in may cases.
You're being shafted by downvoters who don't really know what they're talking about.
>Either it's software running on one chip, or it's software on another chip. That's irrelevant.
No, its not irrelevant. The terms have meaning, regarding the separation. And while it may technically be a misnomer, feigning ignorance to the misnomer to try and point out the misnomer to people who already know about it is not only arguing semantics, but doing so in least constructive way possible.
To address your other post that its all marketing speak, well no, not really. In discussions, what gets called hardware or software conveys meaningful information, but it is highly context sensitive to the bits being discussed at the time, because technically all computing is some combination of hardware and software.
I'm not a dev, but doesn't Apple's Open CL come into play here? is there silicon in iDevices in addition to the GPU which can be used for HW acceleration, whereas Android can only make use of the GPU for this?
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.