How about some Android graphics true facts?
plus.google.com
How about some Android graphics true facts?
1–10 of 109 posts
Re: How about some Android graphics true facts?
#2So I'm guessing that the reason iOS home screen scrolling is faster is because it has much fewer things to draw?
Re: How about some Android graphics true facts?
#3[offtopic]
Isn't saying "true fact" redundant? Unless it's true, how can it be a fact?
[/offtopic]
Re: How about some Android graphics true facts?
#4Is 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.
Re: How about some Android graphics true facts?
#5It 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.
Re: How about some Android graphics true facts?
#6[offtopic] Isn't saying "true fact" redundant? Unless it's true , how can it be a fact ? [/offtopic]
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.
Re: How about some Android graphics true facts?
#7So 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.
Re: How about some Android graphics true facts?
#8It 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…
[deleted]
Re: How about some Android graphics true facts?
#9Those 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.
Re: How about some Android graphics true facts?
#10Android'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 ;-) )