

How about some Android graphics true facts? - Aissen
https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s

======
w0utert
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.

~~~
jan_g
>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
"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.

~~~
jan_g
>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.

~~~
CountSessine
_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.

~~~
mgkimsal
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.
:)

~~~
wnight
Or rather, not from a monopolistic company bent on calling users criminals for
accessing their own devices.

But yeah, if you agree that that describes Apple to a T, or maybe a P, then
"Not Apple, (or Microsoft, or ...)".

------
ugh
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.

~~~
divtxt
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.

~~~
mrich
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.

~~~
mgkimsal
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.

~~~
Synaesthesia
Actually the first time I used an iPad I was blown away by the smoothness of
scrolling in web pages, and it still holds up really well today IMO

~~~
mrich
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)

------
Corun
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
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...](http://developer.android.com/reference/android/view/View.html#getLayerType\(\))
)

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?

~~~
atnan
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.

~~~
babebridou
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.

~~~
alexkcd
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".

------
johnnybgoode
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
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.

------
D_Drake
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
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
[http://theunderstatement.com/post/11982112928/android-
orphan...](http://theunderstatement.com/post/11982112928/android-orphans-
visualizing-a-sad-history-of-support)

------
pmjordan
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.

~~~
hugoc
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

------
apetrovic
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
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
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.

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

~~~
GiraffeNecktie
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).

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

~~~
babebridou
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
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
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 :)

------
hamedh
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.

------
robterrell
Relevant to this discussion is this video:

[http://www.google.com/events/io/2011/sessions/accelerated-
an...](http://www.google.com/events/io/2011/sessions/accelerated-android-
rendering.html)

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

~~~
danssig
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.

------
tseabrooks
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.

~~~
gergles
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_ )

------
Symmetry
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
That actually changes in Android 4.0 (Tested ICS on my Nexus S.. scrolling
nearly instantly starts)

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

------
maximusprime
Hardware rendered vs software rendered??? :/

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

~~~
maximusprime
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
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
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
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.

