Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Follow up to “Android graphics true facts”, or The Reason Android is Laggy

plus.google.com

Post reply on HN
Print view View original

61–70 of 118 posts

Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy

#61

Post by [deleted] »

illumin8 wrote: post #16
saurik wrote: post #10

"""It’s because on iOS all UI rendering occurs in a dedicated UI thread with real-time priority. On the other hand, Android follows the traditional PC model of rendering occurring on the main thread with normal priority.""" """On iOS when an app is installing from the app store and you put your finger on the screen, the installation instantly pauses until all rendering is finished.""" <- This is certainly not true. T…

+1 I think this Saurik guy knows what he's talking about... Now where have I heard that name before? (hint his software runs on over 2 million devices)

[deleted]

Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy

#62

Post by davesims »

Someone wrote: post #42
patrickgzill wrote: post #31

Earlier quoted context omitted.

That jumped out at me as well. I think there would definitely be a way to have most if not all of the underlying API calls set up to do this, without even needing to recompile the application.

If you move code that used to run (and was tested to) on the main thread to another thread, and run that thread in parallel with the main thread, you are creating a huge opportunity for race conditions. Some applications may run fine, but I bet you will find a lot that do not, even ignoring timing differences that may cause problems with games.

I guess I don't see how that's any different than performing any other blocking operation off the main/UI thread, either on a hand-rolled secondary thread or using a util class like AsyncTask which handles that for you.

It seems to me race conditions are no more or less of a concern for rendering animations than updating data -- and probably less, actually, since there's probably not much contention for animation resources, and if there is contention, synchronization of access to drawables should be straightforward.

Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy

#63

Post by podperson »

saurik wrote: post #10

"""It’s because on iOS all UI rendering occurs in a dedicated UI thread with real-time priority. On the other hand, Android follows the traditional PC model of rendering occurring on the main thread with normal priority.""" """On iOS when an app is installing from the app store and you put your finger on the screen, the installation instantly pauses until all rendering is finished.""" <- This is certainly not true. T…

Right -- the first thing I did after reading a few paragraphs was load a complex web page and try scrolling it -- it continues to render just fine (on a single core iPhone 4). I've got a very old iPod Touch which does seem to lock up page draw when I scroll.

I think that the simple answer is that there's no simple answer -- which is what the earlier post was pretty much saying.

Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy

#64

Post by vilya »

interlagos wrote: post #53
vilya wrote: post #47

Earlier quoted context omitted.

That directly contradicts my own experience with Android. I bought a HTC Hero as my first smartphone, so I didn't have any reference points to compare it with. Over 18 painful months of owning that phone I never got used to the lagginess of the UI. Not to the point where it faded into the background, anyway: I learnt to anticipate the lag, but it never stopped being annoying. So much so that when it came time to repl…

There was a dark period in Android's existence where a very immature OS came together with underpowered hardware (the GPU in an iPhone 3G demolished the GPU in the Hero) and created a pretty bad experience. That wasn't what I was talking about. I'm talking about almost imperceptible, frame-or-two jitters that is the current state of Android on virtually any contemporary device. The top selling Android devices are all…

Fair enough, I haven't tried Android on a more recent device so my experience is certainly out of date. But when there are this many people saying there's a problem, surely it would make sense - especially for a fundamentally data-driven company like Google - to do some user studies and quantify it? I haven't heard of any such studies though; do you (or anyone else) know of any?

Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy

#65

Post by vetinari »

rayiner wrote: post #39
interlagos wrote: post #11

Earlier quoted context omitted.

How was the iOS decision more "correct"? Android is clearly succeeding despite the lack of UI refinement, so it's hard to hold one as victorious. There is definitely a different philosophy, though. The Android approach was that it was better to be correct -- if you scroll a page or a webpage, that what scrolls into the viewport needs to be correct, while iOS happily scrolled in a checkerboard. I prefer the stock Andr…

> The Android approach was that it was better to be correct How do you define "correct"? The "correct" behavior is dependent on what you're trying to achieve. What you're trying to achieve should be defined with reference to the user: what will make the user happiest? In a multi-touch interface, where you're trying to maintain the direct manipulation illusion, preserving "feel" at the expense of showing the rendered…

There are big assumptions. Preference for lag or artifacts is subjective (for example, the checkerboard drives me nuts; I prefer occasional shutter). Users will chalk up the checkerboard to device too, as they never seen anything similar on any other device.

Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy

#66

Post by hedgehog »

martingordon wrote: post #51
saurik wrote: post #10

"""It’s because on iOS all UI rendering occurs in a dedicated UI thread with real-time priority. On the other hand, Android follows the traditional PC model of rendering occurring on the main thread with normal priority.""" """On iOS when an app is installing from the app store and you put your finger on the screen, the installation instantly pauses until all rendering is finished.""" <- This is certainly not true. T…

He seems like a smart kid, but he's clearly not developed anything on iOS. One of the key things you learn as you're learning how to build an iOS app is that all UI code must be run on the main thread. It even says so right there in the [UIView class reference]( http://developer.apple.com/library/ios/#documentation/uikit/... ): > Threading Considerations Manipulations to your application’s user interface must occur o…

You're right in general but starting in iOS4:

"Drawing to a graphics context in UIKit is now thread-safe." http://developer.apple.com/library/ios/#releasenotes/General...

Some things won't work (notably UIWebView which also gets used in UITextView) but you actually can build a view in a NSOperation.

Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy

#67

Post by calloc »

wvenable wrote: post #12
sedev wrote: post #2

The takeaway for me is this: Android and iOS' creators made different tradeoffs in their UI programming. The iOS creators, overall, correctly predicted that a fast, smooth, responsive UI was something that users would care about enough that it was okay to pay a performance cost in other areas in order to make the UI as responsive as it is on iOS devices. Android's creators made a different tradeoff, and the UI on And…

Apple is also willing to put a lot of burden on the developers. Having a separate UI thread is more difficult than doing all rendering in the main application thread. Supporting only native code without garbage collection is also more difficult on developers too.

Except that all UI stuff is done in the applications main thread ...

Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy

#68

Post by calloc »

interlagos wrote: post #53
vilya wrote: post #47

Earlier quoted context omitted.

That directly contradicts my own experience with Android. I bought a HTC Hero as my first smartphone, so I didn't have any reference points to compare it with. Over 18 painful months of owning that phone I never got used to the lagginess of the UI. Not to the point where it faded into the background, anyway: I learnt to anticipate the lag, but it never stopped being annoying. So much so that when it came time to repl…

There was a dark period in Android's existence where a very immature OS came together with underpowered hardware (the GPU in an iPhone 3G demolished the GPU in the Hero) and created a pretty bad experience. That wasn't what I was talking about. I'm talking about almost imperceptible, frame-or-two jitters that is the current state of Android on virtually any contemporary device. The top selling Android devices are all…

I have iOS 4.3.x on my iPhone 3G and it stutters compared to iOS 3 at the same time. So much so that when I got my iPhone 4S I noticed how much the iPhone 3G lagged and stuttered that I no longer use it, even as a simple iPod.

Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy

#70

Post by babebridou »

As I said in the other thread, there are two patterns, one is a Delegate pattern (IOS) where draw method lookup per pixel coordinate is trivial, and the other is a listener pattern, where view layout, composition and superposition is trivial. One is easy 98% of the time and super hard 2% of the time (iOS) and the other is relatively slow all the time but with much more potential for cross-process interactions.

In Android, you can have a translucent popups from App#1 appear on top of any sort of screen of App#2. You can't have this on iOS. At all.

On the other hand, animations and scrolling are blazing fast on iOS without any need for superior hardware.

I honestly believe that this alone explains the "lacking" in performance that Android suffers from: it targets super high-end multi-core devices, with JIT compilers and optimizers that don't exist yet, in order to allow functionalities that are unclear to everyone of us.

Shameless plug: I made an app (1) that illustrates what iOS will never be able to do. The question is, will anyone ever need that sort of app on their phone?

(1) https://market.android.com/details?id=com.fairyteller.linkpr...

Post reply on HN