
Android doesn't use the GPU for its UI - basil
http://code.google.com/p/android/issues/detail?id=6914
======
10ren
The Innovator's Dilemma guy also talks about integrated vs. modular
architectures. By integrated, he means made in one elegant piece, meshing
together _just so_ ; by modular he means you can mix-and-match (eg. from
different suppliers, or to customize attributes easily), with clearly defined
standard interfaces. Maybe it sounds like modular is _always_ better; while it
is more customizable and cheaper, integrated can always outperform it. Which
one wins in a market depends on what that market most demands at that time,
with respect to where the technology is at that moment. Is it fast enough?
Does it have enough functions? Is it flexible enough? Is it cheap enough?
Markets tend to move back and forth between them, as they evolve over a period
of years.

For smartphones, performance is still an issue (and will be for 2-3 years I'd
guess, by Moore's law), and so integrated platforms do the best job at this.
This is Apple's forte - but they have limited time to make hay and get as
firmly established as possible.

It's limited, because once the market's demand for performance is sated ("fast
_enough_ "), the market will base decisions on other issues - such as price.
And that is not Apple's forte, nor does Apple want it to be. Thus, Apple
already has the iPad lined up. After that, there'll be in another market at a
stage where Apple's extraordinary ability to integrate can shine.

To be clear: Android is _modular_.

~~~
StavrosK
When were computers fast enough? Each computer I've gotten is exactly as fast
as the previous one, from the 100 MHz pentium I had in 97 to the quad core I
have now. Programs do more things, but that's why the speed has remained the
same.

My only hope that this will change is with SSDs. I swapped my laptop's SSD for
a HDD and now it's a dog, which reminded me how big the difference in
performance is.

~~~
10ren
Allow me to answer in terms of integrated vs. modular architectures: they were
fast enough when Java's virtual machine became viable, when .Net's virtual
machine became viable, when interpreted scripting languages (Javascript,
Python, Ruby) became viable.

Basically, whenever an extra layer that soaked up performance in return for
other benefits (such faster development time, better error checking, more
flexibility, easier, more intuitive) was actually adopted by real people, it
meant that the computer was fast enough in their opinion to trade some of that
fastness for other benefits.

relevant: <http://xkcd.com/676/>

~~~
10ren
Garbage collection (mentioned in the article) is also a great example of
integrated vs modular, with the same tradeoffs: when you handle it manually,
it is integrated with the code - and it's possible to optimize/customize its
performance much better than an automatic garbage collector.

An automatic garbage collector is a separate module: the details are separated
from your code; different garbage collectors (with different
strategies/tradeoffs) can be used without affecting your code; and development
is cheaper.

------
edderly
The actual question should be why isn't the UI faster and more responsive?
Stating a solution as a requirement is rarely a good idea.

We know that the iPhone and Droid (and successor Droid X) has pretty similar
hardware, both license the GPU IP block from Imagination Technologies.
[http://www.anandtech.com/show/3826/motorola-droid-x-
thorough...](http://www.anandtech.com/show/3826/motorola-droid-x-thoroughly-
reviewed/5)

However, we do have some details missing in comparison with the iPhone. For
example, do we know whether Apple's UI is h/w accelerated? If it is, does the
GPU have dedicated graphics memory (and how much?) or could a blitter be used?

AFAIK, most if not all Android phones will have a GPU just simply as a
function that Surfaceflinger (the Android window compositor) is an OpenGL
implementation. It's only the emulator and during bring up that you'd use the
software implementation of libagl/OpenGL.

There's also a question that how good is a mobile SoC GPU at doing 2D. As
mentioned, it isn't de rigueur that a mobile GPU has dedicated (fast) memory
which is completely different in the PC space which has copious amounts. In
the Droid X case you're weighing a 1GHz CPU vs 200Mhz GPU with a small number
of cores. In fact, consider that we're fairly used to spending as much if not
more for the GPU in desktop systems as the CPU.

I do know for a fact that Imagination's 2D interface (PVR2D) has a large setup
overhead which makes blitting of small bitmaps very slow, but somewhat ok with
larger bitmaps. Add, alpha and it sucks in any case.

You shouldn't also discount that perhaps the Android UI and app. framework is
naively implemented compared to Apples.

~~~
newhouseb
It's pretty straightforward to observe how iPhone's Safari is accelerated
while Androids is not by using CSS 3D transforms.

Google's original 2D layer (Skia) can only render affine transforms and not
perspective transforms in webkit (largely because it just hasn't been
configured in WebCore). Mobile Safari can in fact render perspective
transforms indicating that it is using a different graphics engine than Skia
(in fact Apple's documentation says that it is hardware accelerated).

While this is only concerning the browser it allows for some benchmarks - try
any transitions or 3D transforms in the browser and you'll find them much
faster on the iPhone. Additionally Skia, which is used in Android's browser is
used elsewhere in Android as well so its performance characteristics are more
broadly relevant beyond just web browsing.

------
Osiris
In my opinion, one of the main reasons people like the iPhone/iPad is the look
and feel including the icons, animations, transitions, etc. The fact that iOS
has included hardware acceleration from the very beginning speaks to how
important the user experience was for them and using the GPU allowed them to
provide a faster, smoother user experience.

I have to admit that the user experience in Android is severely lacking and is
no where near as good as iOS. Let's hope this gets addressed in Gingerbread
both for the core OS and for third-party apps.

~~~
ryanhuff
This is one reason why I am not counting out Microsoft with their new WP7
platform. Your average U.S. consumer makes their device purchase decisions in
the wireless carrier store. If Android and WP7 are shown side-by-side in a
showroom (assuming comparable hardware and price) my bet is that windows phone
will win its fair-share of battles given its approachable and responsive
interface.

~~~
sprout
My Motorola Droid doesn't stack up against Apple, but I've played with both
Apple store and current-gen Verizon phones, and the current-gen Verizon Droids
are just as responsive as Apple hardware. I'm not sure this GPU thing is much
of an issue anymore.

To be fair, my experience with them is mostly playing with them in the store,
but as you say, that's where it counts. In day-to-day usage it tends to be
less of a big deal. You adjust how you use the device.

~~~
achompas
_In day-to-day usage it tends to be less of a big deal. You adjust how you use
the device._

I'd argue the opposite when it comes to UI. If you're tapping on the same link
2-3 times bc you're not sure whether Android/iOS registered the tap, that's an
intractable problem that gets worse with time. You can't adapt your behavior
to that annoyance.

~~~
adbge
In a sense, you're both correct. It really depends on the user and the UI
annoyance. A lot of UI quirks become second nature to power users and they
don't even notice them, but things like lagging on a keypress, etc, is
probably going to be a persistent source of annoyance.

iPhone users, for example, don't seem to mind life without a back button. It
becomes a fact of life and users adapt their usage of the device accordingly.

On the other hand, when I updated my iPhone 3G to iOS 4, the responsiveness of
the UI suffered by _orders of magnitude._ After more than a month of usage, I
still found things like typing a text message excruciating. (Mostly fixed with
the 4.1 update, praise god.)

------
nl
Did anyone else notice how early on in the bug Google's Romain Guy pointed out
that _The "choppiness" and "lagginess" you are mentioning are more often
related to heavy garbage collection than drawing performance_ as well as
saying that newer devices might allow them to use the GPU as well.

Did anyone pay any attention to that, and ask sensible questions about tuning
that? Of course not...

On the Galaxy S (under Android 2.1) for example, the lagging seems to be
caused by keeping temporary data on the slow, internal SD memory. That can be
fixed by moving it to external memory, and there is a one-click fix for it in
the Market. That fix _triples_ the phones performance in some benchmarks, and
has completely solves any lagging issues for me.

It's possible the HTC phones suffer from a similar problem, but here everyone
assumes it's the GPU so you'd never know.

 _Never performance tune without benchmarking first. You'll fix the wrong
thing_

------
grantheaslip
The complete lack of responsiveness in the Android UI, regardless of how
difficult it is to fix, needs to be remedied, and needs to be top priority.

The UI is the connection between the user and the device. When it's laggy and
unresponsive, the experience of using the device is always going to be sub-
par, no matter how many new features and optimizations the developers have
added.

Whenever I've had a chance to test out the latest and greatest Android phone,
I've always been blown away by how awful the scrolling performance and
animations are, to the point where I really don't understand how people put up
with it on a day-to-day basis. My iPhone 3G, at least when it's not randomly
hanging due to 4.0, feels more responsive than any Android phone I've tried,
and it's running on 3+ year-old hardware (it's got the same processor and
memory as the iPhone 2G, IIRC).

Smooth animations, not benchmark results, are equivalent to speed to the
average person, and who can blame them?

~~~
slantyyz
Even the -illusion- that it's working quickly will help. Remember those
checkerboards that would show up on the iPhone when the screen couldn't paint
fast enough? People tolerated it because the -activity- on the screen matched
what the user's finger was doing.

I find it a weak defense for Android by saying "well the newer phones don't
have that problem". Most people can't afford to change their phones with every
new hardware rev, so it does matter that the OS makes every attempt to make
all user experience optimizations on any given piece of hardware. You can't
rely on Moore's law to improve usability for existing customers.

With the exception of the 4.0 OS upgrade, I can't say that I've had major
performance complaints on the iPhone 3G either. Myself, I'd like to use my
current phone as long as possible before giving any phone manufacturer more of
my money.

------
andreyf
It's interesting to realize that one could be holding a phone and using a
fraction of its computational capacity because the two companies that
collaborated on creating it... don't talk enough?

~~~
st3fan
It can also simply be a matter of available (human) resources. Remember how
the iPhone was missing Copy & Paste? Probably not because they did not know
how to do it. More likely simply a matter of shipping priorities and
resources. I think the same is going on here.

~~~
mattparcher
While this is a good case for prioritization, I would argue that Google has
made a mistake by allowing the _fundamental interaction model_ of the phone to
suffer from unnecessarily poor performance, either by taking less-than-full
advantage of the GPU or (less likely?) not dealing with the problem of “heavy
garbage collection” that is cited by the first project member to respond on
the linked thread.

Copy and paste functionality is nice, but smooth-as-butter scrolling and near-
instant responsiveness, a la iPhone, (or lack thereof) arguably _define_ the
experience.

------
fauigerzigerk
I find that piece pretty interesting: "The "choppiness" and "lagginess" you
are mentioning are more often related to heavy garbage collection than drawing
performance.".

Wasn't that supposed to be a thing of the past with modern garbage collectors?

~~~
ergo98
It's the downside of all GCs, and I've yet to see one that alleviates it.

It does seem likely that it is GC issues and not whether the GPU is used or
not: The visual choppiness is completely inconsistent, lending itself more to
brief thread stops for GCs than to any sort of CPU starvation.

On the bright side, it is far less common on 2.2 than before. It still is by
no means a deal breaker, but pretty much every user of both the iPhone and
Android makes note of the much more consistent smoothness of the former.

~~~
dkarl
I bet Android has a lot of room to improve not just by improving garbage
collection but by decreasing garbage creation. The compiler can do a lot of
optimizations to reuse objects instead of allocating new ones. I don't know
what the state of the Android JIT is, but Sun's JIT took many years to
incorporate some basic-seeming optimizations.

One thing that could be done in the meantime is to rewrite performance-
sensitive Android UI code in a way that eliminates object allocation. In Java
this would result in horrifying code, but it might be worth it, and they
wouldn't necessarily have to use Java.

~~~
blasdel
Android's Dalvik VM has only had a JIT for 4 months (shipped in 2.2)

Hilariously enough, they started using V8 in 2.0 a year ago — so in 2.0 and
2.1, Javascript is JIT-ed but Java isn't!

------
hammerdr
If you read between the lines, the reason they have tried and failed to
implement this is fragmentation of the market. While more modern devices would
likely support GPU usage, the older devices (or even new low end devices?)
would not. So they either have to live with the current fragmentation or
fragment the market even more.

Fragmentation is, of course, a huge point for Android detractors. This is a
very real manifestation of that which shows that Android may stagnate in the
future due to the inability to develop features for a significant number of
devices.

However, for the most part, Android as it sits today has a low level of
fragmentation compared to what could happen. I recently developed an Android
app for 1.6-2.2 and only had a couple fragmentation issues (performance
related and contacts API). Google and its partners really need to take a long
look at the direction of Android and resolve the fragmentation now while its
possible.

~~~
msg
Why can't they just wait for the market to move forward? My G1 is almost 2
years old, meaning time for a subsidized upgrade. In a few months I'm going to
have Flash on my phone for the same price I paid (about $200) for 1.6.

Google has said before that it is going to break out the user interface
portions of the OS so they can be updated without a (carrier in the loop) OS
upgrade. To me that says that OS level innovation is going to slow, and so
will fragmentation. At that point the only thing stopping you from taking
advantage of an Android feature will be horsepower.

------
tmsh
Apple run loops are more flexible and adaptable than this

[http://android.git.kernel.org/?p=platform/frameworks/base.gi...](http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=core/java/android/os/Looper.java)

via [http://stackoverflow.com/questions/3321587/anatomy-of-an-
and...](http://stackoverflow.com/questions/3321587/anatomy-of-an-android-run-
loop)

but since Looper is OSS it should be improved. Here's an idea, make it
customizable like NextStep/Apple's architecture. Be able to change run loops
on the fly when scrolling, select on different input sources, etc. Could be as
simple as that...

Or if you want the long answer, it could be NextStep's key design choices
which have paid off over the past decade.... Might as well learn from them.
Will really flexible run loops solve single OGL context issues? Probably not.
But they might just make things less jerky...

------
codedivine
Btw, Symbian^3 does actually feature a hardware accelerated UI layer and
should remove much of the "slowness" of the S60 5th edition.

