

Dianne Hackborn responds again about android graphics - brian_cloutier
https://plus.google.com/u/0/105051985738280261832/posts/XAZ4CeVP6DC

======
nkurz
I just did an interesting side-by-side test of scrolling within a browser
displaying Google on an new iPhone 4 and an older Android phone (HTC
Incredible. I didn't actually see much difference as to how "smooth" or
"choppy" the scrolling was, but there were distinct differences to fast
motions.

The iPhone seemed better at keeping up with a fast moving finger. If you put
your finger on a line at the top of the screen, and scrolled quickly until
your finger was at the bottom, the same line would still be under your finger.
On the Incredible, the line you started on would only end up 2/3 of the way
down the screen.

More surprisingly, this seemed to happen to a lesser extent even on very slow
scrolls. Put you finger down on a line, drag it to the bottom, and the amount
scrolled is always significantly less than the distance your finger moves.
Rather than being a rendering problem, this seems more like an event loop that
throwing away some of the events!

~~~
rubinelli
Touch gestures generate a ton of events, specially in early versions. The most
common fix is sleeping for a few ms in the UI thread.
[http://www.badlogicgames.com/wiki/index.php/Touch_Event_Floo...](http://www.badlogicgames.com/wiki/index.php/Touch_Event_Flooding)

~~~
joezydeco
I have to kind of wonder if Apple is buffering touch events on their
_controller_ and then sending them onward to the UI as postprocessed events
and gestures.

Maybe I'm the only one left with a boggy 3G running iOS4, but when the system
lags down I can usually keep typing and the keystrokes will catch up. Does the
same thing happen on Android?

If gesture processing is being done on the controller side, that would take a
lot of perceived bog out of the UI.

------
mirkules
This post basically amounts to: "There is no problem with graphics on android,
it was designed to work this way because of the open nature of android, and
other excuses"

Well, the design is broken then. Clearly, it is possible to achieve a smooth
UI as demonstrated by iOS and have a solid and stable system. This post is
actually worse than saying "we can't fix it" -- it's denying a problem exists
in the first place, because "hey, we do it just like iOS." Except it doesn't
work like iOS.

I recently went back to iPhone because I got so frustrated with Android's
jerky UI on my 1-year-old phone (Galaxy S). I went back to a iPhone 3GS that
runs iOS 5 faster than the Android ran Froyo (which, btw, I had to jump
through 30 different hoops just to upgrade from 2.1). The takeaway is this:
Android lost a customer because of slow, laggy UI, and I'm sure I'm not the
only one.

~~~
inoop
Java is memory safe, and classloaders have been used since forever to sandbox
applications (remember applets?). The whole 'designed to be open' argument is
nonsense.

Let's face it, Android was hacked together by a small team on a deadline. It
doesn't seem like a lot of thought went into the design and architecture of
the system. The code is buggy, there are no tests, and half the tree doesn't
even have comments. Bug reports are ignored, and there are about 22k open
issues that are not even being triaged. Case in point:
<http://code.google.com/p/android/issues/detail?id=19078> (not fixed in ICS)

Android is a rush-job, and the team's obvious lack of experience in handling
large software projects is biting them in the ass. Rather than making excuses
for their botched together software maybe they should just get their shit
together.

~~~
comex
> Java is memory safe, and classloaders have been used since forever to
> sandbox applications (remember applets?).

Well, except that Android allows apps to run arbitrary native code using the
NDK.

~~~
inoop
> Well, except that Android allows apps to run arbitrary native code using the
> NDK.

I was under the assumption that they can support native code because of the
way they designed Android, not the other way around. I highly doubt that
supporting native code was the design rationale here. I think they just
designed Dalvik to use Linux threads and assume it to run inside its own
process. That certainly makes things much simpler for the VM. The fact that
you can safely load native code follows naturally.

Still, supporting native code does not have to dictate how you ensure memory
protection, or whether each app has to run inside its own process. You can
always run a native library (i.e. a video codec) inside a separate process and
use memory-safe communication with the process that runs the Java app. You can
also go the NACL route.

There's absolutely no reason why supporting native code would result in a
choppy UI on Android.

------
zobzu
Devil's tongue: "This is very different from iOS’s original design
constraints, which remember didn’t allow any third party applications at all."

This argument resume the whole article's _intent_. I'm not using iOS. I
dislike Apple's way of enforcing it's products. But I know BS when I see it.
iOS's security and sandboxing, while technically different, is practically
similar to android. Each app is sandboxed. Oh and guess what, the AppStore let
you install third party apps, and since before Android became Google's
Android.

And for the actual thing that matters, Android uses multiple GL contexts by
design, iOS doesn't, so Android is slower.

~~~
Xuzz
iOS has multiple processes on the system using hardware acceleration at the
same time, and always has. A few examples are the system-rendered status bar
at the top of the screen, or the "Notification Center" that you pull down from
the top, or even the little volume adjustment popups. All of those are
hardware accelerated and rendered out-of-process in the system UI manager
("SpringBoard"), not inside the app.

Both of those have smooth scrolling and animations, at the same time,
overlayed on top of each other. I don't think there's anything here in iOS
that shows the lack of "multiple GL contexts"; and I definitely don't think
that is a significant contributor to making anything slower.

------
mikhael
Probably the key paragraph, in relation to the recent discussion:

> In fact it was just not feasible to implement hardware accelerated drawing
> inside windows until recently. Because Android is designed around having
> multiple windows on the screen, to have the drawing inside each window be
> hardware accelerated means requiring that the GPU and driver support
> multiple active GL contexts in different processes running at the same time.
> The hardware at that time just didn’t support this, even ignoring the
> additional memory needed for it that was not available. Even today we are in
> the early stages of this -- most mobile GPUs still have fairly expensive GL
> context switching.

~~~
chwahoo
So an attempt at a brief summary of (the non-thread-priorities portion of) her
post:

The Android model of providing rendering isolation between apps/windows has
limited hw acceleration of window contents rendering, which is a cause of some
of Android's lagginess. That iOS forgoes this isolation and achieves better
responsiveness is a reflection of a different security philosophy.

If this is an accurate summary, it's an interesting example of how platform
design is wicked problem with complex interactions between concerns that you
might expect to be orthogonal.

~~~
campnic
That sounds accurate to me. I'm not sure if its simply that iOS forgoes
isolation or they've implemented isolation in a mechanism that allows for the
context to be shared without security consequence.

~~~
ryanpetrich
On iOS, all standard rendering is done in a single context by the Core
Animation window server which lives in SpringBoard. Only when an app adds an
OpenGL ES layer to the view hierarchy does a separate context need to be
created. When that happens, the render graph is split into subgraphs that are
rendered to surfaces and displayed as overlays (with SpringBoard rendering all
the standard layers and the app rendering the OpenGL layer)

------
nubela
There is one thing that can be observed here, imho. That iOS was made to be
sleek right from the start, from there they sacrificed pragmatic system
design, which efficiently crimped a lot of flexibility; flexibility such as
3rd party input, etc, of which has gotta be now implemented from system up.

As an Android user, given my (now) better understanding of the Android
architecture design, I am happy and safely say that Android was made for the
future, and is only gonna get better from here on.

~~~
foobarbazetc
Your views make no sense.

iOS applications also run in separate processes and are just as secure as
Android apps. There's nothing "made for the future" in the poor up front
design choices the Android team made early on.

In fact, we can clearly see that the iOS team made _all the right decisions_
because drawing/compositing in iOS on a 3GS is faster and smoother than on a
shiny new Android Inspiration XL HD 4G.

Also, Dianne shows a fundamental misunderstanding of how drawing/compositing
works on iOS. So this entire series of posts is just moot. The other guy
(Windows Phone guy) had no idea how Android or iOS worked, either.

The most annoying thing about all this is that none of these views are based
on actual facts -- and we all know what happens when someone is wrong on the
Internet.

At the end of the day, who cares which one is better or how it's implemented?
I don't care about the "Android has windows" explanation because it's
irrelevant to me as an end user. It's all about perception.

This entire Android vs iOS thing is getting long in the tooth.

Edit: also, it's going to take a long, long time to be able to pull off
something as awesome as Core Animation. Or Core Text. Or Core Graphics. These
things have been stewing in OS X for more than a decade.

~~~
campnic
First, what poor design choices did they make? The entire post was attempting
to debunk the perception that there was some simple decision that leads to the
issues people describe. Second, I don't believe Dianne has a fundamental
misunderstanding of anything regarding a mobile OS as she is one of the most
preeminent people in the field.

Its frustrating and annoying to read posts like this where you try to walk a
"I'm impartial" line and then pepper it with biased remarks that are
misleading. You are unlikely to get more factual discussion about the
situation then the post she offered, as she's a creditable expert who has
written a not insignificant portion of the OS under discussion.

Its clear that iOS has some really technical achievement they should be proud
of, but your desire for facts about the situation is subverted by your very
own use of statements like "drawing/compositing in iOS on a 3GS is faster and
smoother than on a shiny new Android Inspiration XL HD 4G" without anything to
support your position. Its not a fact because you make a statement.

~~~
saurik
Well, she does (have a fundamental misunderstanding of something regarding a
mobile OS): she is an Android developer, and it is pretty clear from this
article that she has no clue what she is talking about when it comes to iOS.

Seriously: you should trust Xuzz from this thread much more than Dianne about
issues related to iOS surface compositing. Xuzz worked on jailbreakme with
comex, did much of the work for the recent Siri-on-non-iPhone-4S ports, and
has written numerous modifications to the code of SpringBoard (the main window
manager and graphical shell process on iOS) over the last few years he has
spent reverse engineering that system, and most of his posts on this thread
are corrections to statements that Dianne seems to have simply made up for
this article of hers.

(For "people to watch" on this thread, I should also point out ryanpetrich,
who is responsible for such modifications as DisplayRecorder (which records
the iOS framebuffer to a video file) and DisplayOut (which splits the
framebuffer out to a television), both available for jailbroken devices.)

------
erichocean
The part about the graphics contexts and process limitation is key, and an
area where iOS is far ahead of Android, since iOS does not have that
limitation.

(Neither does Mac OS X, and it took Apple years and years to get to that point
-- each year at WWDC you'd see more and more of the UI hardware accelerated.)

------
nuje
The Android sandboxing feature is frequently invoked as providing dramatic
security advantages, but there's really no reason to believe it.

Local privilege vulnerabilities [edit: enabling escape from the sandbox] in
Linux kernel are dime a dozen, and Android phones are notoriously outdated wrt
security patches.

There simply hasn't been a lot of OS level vulnerability exploitation in
Android malware so far. Probably the biggest reason is OS fragmentation +
malware apps can just request any privileges they need on the market and the
users will haplessly click accept, and the biggest threat to the malicious
apps is Google removing them from the Market when they're found out.

------
Udo
It's easy to understand the point that window management in Android is complex
and this complexity hampers graphics performance. On iOS, one process has the
entire screen at a time. There are no widgets, no plugin viewports, no 3rd-
party UI - but all this stuff _is_ happening on Android. The question becomes
whether this is actually a good paradigm to have for a mobile platform and
whether this compartmentalization mechanism is really needed.

For example, take this statement: " _This [window management technique] is
also why Android can safely support third party input methods._ " Clearly, the
perception at Google is that this model makes Android safe, and in a way
that's understandable because the platform is way more open than iOS and thus
needs more inherent resistance. But look at the concept of "safe support" for
third party input methods. But does compartmentalization of UI operations in
this case actually make, say, 3rd-party keyboards safe to use?

~~~
daniel_solano
It all depends on what you mean by "safe". It is certainly possible to create
input methods that behave as spyware, that's why Android puts a big fat
warning telling you so whenever you switch to a third-party input method.

I think what is meant by safe in this context is that an that is not an input
method cannot pretend to be one. Likewise, the interface between the input
method and applications means that an application cannot normally wire itself
into the input method and monitor everything the user types.

~~~
Udo
Yes, exactly, it's very open to debate what safety in this case actually
means.

    
    
      I think what is meant by safe in this context is that an 
      that is not an input method cannot pretend to be one.
    

But is that really a concern? If you're putting together a spyware app
disguised as a keyboard, why not just include a keyboard and "fool" this
protection by actually providing the advertised functionality?

I also believe that the Android people in this specific case define "safe" as
"safe from crashes" in the way that a 3rd-party external component cannot
easily crash the foreground app because of the windowing and thread-based
compartmentalization.

------
smackfu
HN on previous post: <http://news.ycombinator.com/item?id=3310301>

------
D_Drake
Users: Wow, android is neat, but why is the interface performance so crappy?
Google: _silence_ Users: Hmm, I bet it's X, because of ____. Google: No, no, X
in android is great, it's awesome, and even if it weren't awesome it totally
wouldn't be the cause of anything anyone might think is bad.

Users: Ok, hmm, then I bet the clunkyness and chippiness are due to Y, because
of _____ and _____. Google: No, no, Y is actually great in android; android
has had Y since the beginning. Users: Ok, so why is the android interface
universally clunky? Google: _silence_

"I am not writing this to make excuses for whatever things people don’t like
about Android"

Dianne, don't you dare insult our intelligence by pretending the worst thing
about the android experience is a case of personal preference by a small group
of loonies.

<http://i.imgur.com/e8S63.jpg>

