12 ms·

How about some Android graphics true facts?

219 points by Aissen 15y ago

StavrosK 15y ago
So I'm guessing that the reason iOS home screen scrolling is faster is because it has much fewer things to draw?
- babebridou 15y ago
  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.
  - th0ma5 15y ago
    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?
    - babebridou 15y ago
      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 :)
Garbage 15y ago
[offtopic] Isn't saying "true fact" redundant? Unless it's true, how can it be a fact? [/offtopic]
- brudgers 15y ago
  Example from football (soccer): In the opinion of the referee, the ball did not cross the goal line between the posts and below the crossbar despite the ball actually doing so. However the fact is in accord with the referee's opinion, not the actual path of the ball.
- m_for_monkey 15y ago
  You are right, I hate that phrase too. Unfortunately it's pretty widespread. From my Collins Cobuild 5 dictionary: "When you refer to something as a fact or as fact, you mean that you think it is true or correct." See also: http://www.thefreedictionary.com/fact http://www.thefreedictionary.com/fact Although, the Wikipedia disagrees: http://en.wikipedia.org/wiki/Fact#Etymology_and_usage http://en.wikipedia.org/wiki/Fact#Etymology_and_usage
- GiraffeNecktie 15y ago
  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).
- eggnet 15y ago
  In logic and philosophy, a fact is a proposition that can be true or false.
johnnybgoode 15y ago
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.
- nknight 15y ago
  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.
w0utert 15y ago
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.
- deleted 15y ago
  [deleted]
- jan_g 15y ago
  >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.
  - mgkimsal 15y ago
    "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.
ugh 15y ago
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.
- babebridou 15y ago
  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...
  - tseabrooks 15y ago
    I own a Toshiba Thrive for various reasons... and it's UI is a laggy steamy POS. Maybe it's manufacturer specific.
  - seclorum 15y ago
    > 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.
Corun 15y ago
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 ;-) )
- Corun 15y ago
  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.html#getLayerType() 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 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?
  - 15y ago
D_Drake 15y ago
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.
- nextparadigms 15y ago
  A lot of the 2011 phones should be updated to Android 4.0, and the ones who bought them in 2010 will upgrade next year to Android 4.0 phones.
  - kalid 15y ago
    http://theunderstatement.com/post/11982112928/android-orphans-visualizing-a-sad-history-of-support http://theunderstatement.com/post/11982112928/android-orphan...
  - D_Drake 15y ago
    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.
- adgar 15y ago
  > We actually have no idea why that is. Way to take what started as a reasonable post and trash it with a needless, baseless insult.
  - D_Drake 15y ago
    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.
maximusprime 15y ago
Hardware rendered vs software rendered??? :/ It's all just software. The only thing that matters is how fast it is.
- maximusprime 15y ago
  Downmodders: Can you explain why? 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.
  - angrycoder 15y ago
    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.
    - maximusprime 15y ago
      No, they both involve software, writing to a framebuffer. (By software, I mean code - software/firmware/etc). A crappy 'hardware' accelerated GPU can be slower than a 'software' framebuffer write. My point was that saying "It's hardware accelerated" is meaningless marketing speak.
      - atnan 15y ago
        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.
  - tikhonj 15y ago
    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.
apetrovic 15y ago
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.
- nknight 15y ago
  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".
  - adgar 15y ago
    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.
tseabrooks 15y ago
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.
- ElliotH 15y ago
  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.
- StavrosK 15y ago
  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.
- gergles 15y ago
  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)
- usaar333 15y ago
  Launcher Pro has near zero lag on even older devices. ICS definitely has little scrolling lag (tested on Nexus S)
robterrell 15y ago
Relevant to this discussion is this video: http://www.google.com/events/io/2011/sessions/accelerated-android-rendering.html http://www.google.com/events/io/2011/sessions/accelerated-an...
pmjordan 15y ago
From the article: 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.
- demallien 15y ago
  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.
- hugoc 15y ago
  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
albertzeyer 15y ago
Why is it that OpenGL adds any overhead? I doubt this is the case on iOS.
hamedh 15y ago
Will Android 4 still redraw everything when rotating the phone instead of animating? This is not only a bad experience for users but also is one of the most difficult parts when developing Android apps.
Symmetry 15y ago
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.
- usaar333 15y ago
  That actually changes in Android 4.0 (Tested ICS on my Nexus S.. scrolling nearly instantly starts)
resnamen 15y ago
The comments in these gadget threads are so polarized, it's positively toxic.
- danssig 15y ago
  Not enough people have read an understood pg's essay on ID. People are making the gadget a part of themselves so they behave irrationally about it.

219 points by Aissen 15y ago

StavrosK 15y ago

So I'm guessing that the reason iOS home screen scrolling is faster is because it has much fewer things to draw?

babebridou 15y ago
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.
- th0ma5 15y ago
  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?
  - babebridou 15y ago
    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 :)

Garbage 15y ago

[offtopic] Isn't saying "true fact" redundant? Unless it's true, how can it be a fact? [/offtopic]

brudgers 15y ago
Example from football (soccer): In the opinion of the referee, the ball did not cross the goal line between the posts and below the crossbar despite the ball actually doing so. However the fact is in accord with the referee's opinion, not the actual path of the ball.
m_for_monkey 15y ago
You are right, I hate that phrase too. Unfortunately it's pretty widespread. From my Collins Cobuild 5 dictionary: "When you refer to something as a fact or as fact, you mean that you think it is true or correct." See also: http://www.thefreedictionary.com/fact http://www.thefreedictionary.com/fact Although, the Wikipedia disagrees: http://en.wikipedia.org/wiki/Fact#Etymology_and_usage http://en.wikipedia.org/wiki/Fact#Etymology_and_usage
GiraffeNecktie 15y ago
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).
eggnet 15y ago
In logic and philosophy, a fact is a proposition that can be true or false.

johnnybgoode 15y ago

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.

nknight 15y ago
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.

w0utert 15y ago

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.

deleted 15y ago
[deleted]
jan_g 15y ago
>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.
- mgkimsal 15y ago
  "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.

ugh 15y ago

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.

babebridou 15y ago
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...
- tseabrooks 15y ago
  I own a Toshiba Thrive for various reasons... and it's UI is a laggy steamy POS. Maybe it's manufacturer specific.
- seclorum 15y ago
  > 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.

Corun 15y ago

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 ;-) )

Corun 15y ago
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.html#getLayerType() 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 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?
- 15y ago

D_Drake 15y ago

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.

nextparadigms 15y ago
A lot of the 2011 phones should be updated to Android 4.0, and the ones who bought them in 2010 will upgrade next year to Android 4.0 phones.
- kalid 15y ago
  http://theunderstatement.com/post/11982112928/android-orphans-visualizing-a-sad-history-of-support http://theunderstatement.com/post/11982112928/android-orphan...
- D_Drake 15y ago
  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.
adgar 15y ago
> We actually have no idea why that is. Way to take what started as a reasonable post and trash it with a needless, baseless insult.
- D_Drake 15y ago
  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.

maximusprime 15y ago

Hardware rendered vs software rendered??? :/ It's all just software. The only thing that matters is how fast it is.

maximusprime 15y ago
Downmodders: Can you explain why? 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.
- angrycoder 15y ago
  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.
  - maximusprime 15y ago
    No, they both involve software, writing to a framebuffer. (By software, I mean code - software/firmware/etc). A crappy 'hardware' accelerated GPU can be slower than a 'software' framebuffer write. My point was that saying "It's hardware accelerated" is meaningless marketing speak.
    - atnan 15y ago
      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.
- tikhonj 15y ago
  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.

apetrovic 15y ago

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.

nknight 15y ago
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".
- adgar 15y ago
  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.

tseabrooks 15y ago

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.

ElliotH 15y ago
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.
StavrosK 15y ago
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.
gergles 15y ago
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)
usaar333 15y ago
Launcher Pro has near zero lag on even older devices. ICS definitely has little scrolling lag (tested on Nexus S)

robterrell 15y ago

Relevant to this discussion is this video: http://www.google.com/events/io/2011/sessions/accelerated-android-rendering.html http://www.google.com/events/io/2011/sessions/accelerated-an...

pmjordan 15y ago

From the article: 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.

demallien 15y ago
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.
hugoc 15y ago
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

albertzeyer 15y ago

Why is it that OpenGL adds any overhead? I doubt this is the case on iOS.

hamedh 15y ago

Will Android 4 still redraw everything when rotating the phone instead of animating? This is not only a bad experience for users but also is one of the most difficult parts when developing Android apps.

Symmetry 15y ago

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.

usaar333 15y ago
That actually changes in Android 4.0 (Tested ICS on my Nexus S.. scrolling nearly instantly starts)

resnamen 15y ago

The comments in these gadget threads are so polarized, it's positively toxic.

danssig 15y ago
Not enough people have read an understood pg's essay on ID. People are making the gadget a part of themselves so they behave irrationally about it.