Follow up to “Android graphics true facts”, or The Reason Android is Laggy • Hacker News Board

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

#31

Post by patrickgzill » Mon, Dec 05, 2011, 9:09 PM UTC

davesims wrote: post #6

“...a lot of the work we have to do today is because of certain choices made years ago... ...having the UI thread handle animations is the biggest problem...An easy solution would of course to create a new UI toolkit but there are many downsides to this also.” What would such a re-write look like, from a practical coding point-of-view? Couldn't this be done in a way that is transparent to the calling code, or would t…

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.

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

#32

Post by eridius » Mon, Dec 05, 2011, 9:14 PM UTC

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…

Agreed. The writer here doesn't seem to know what he's talking about. The reason things like WebKit tiles and images in tables don't populate while you're actively scrolling is because of an intentional choice on the part of the programmer. When you're touching the screen the run loop is put into a different mode than the default, and authors tend to write code such that expensive operations (like populating thumbnails in a table) simply don't occur unless the run loop is in the default mode. In fact, a naïve implementation of a tableview with thumbnails will populate those thumbnails as you scroll, and this has a noticeable effect on frame rates.

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

#33

Post by Groxx » Mon, Dec 05, 2011, 9:14 PM UTC

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…

On the second point, you're correct for 5.0 at the very least - I just tried it. Touching and even actively panning back and forth (never releasing) doesn't even pause the loading-bar updating, and I even discovered badges update during this as well.

For 4.x, if I remember correctly, it would pause the rendering. But I experimented a little then too, and it didn't pause the install at all - it'd just jump when you released.

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

#34

Post by rayiner » Mon, Dec 05, 2011, 9:14 PM UTC

interlagos wrote: post #8

This isn't a "follow-up", per se. Nonetheless, while Android continually works to smooth out the rough edges -- helped along by the march of technology -- this is something that is a bit overblown: Minor jutters of the interface is something that primarily irritates people as a relative thing, not as an absolute thing. If you are a developer or a reviewer and you regularly use an iOS device and an Android device, the…

> If you are a developer or a reviewer and you regularly use an iOS device and an Android device, the difference is evident and jarring. If you're an end-use it quickly disappears and is a non-issue. It just isn't a real problem for end users.

Except when they're trying out different devices looking to buy one.

Also, to a certain extent people put up with stuff like this because they don't know it can be better. E.g. Windows's shitty move/resize for all those years. But do you think, in the face of OS X, Windows could've continued to do without compositing up to now?

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

#35

Post by anon1385 » Mon, Dec 05, 2011, 9:22 PM UTC

code_duck wrote: post #18

I'd be interested to learn what the deal is with sound on Android. I'm a musician and love the software instruments on the iPhone/iPod touch... they're a joy to play. On my relatively modern Android phone (Motorola Droid 2), instruments are so laggy they are absolutely unplayable. A key press results in a sound up to half a second later, sometimes never. The response improved slightly with the upgrade to Gingerbread,…

It's a known issue and people have been complaining about it for years now: http://code.google.com/p/android/issues/detail?id=3434

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

#36

Post by randomdata » Mon, Dec 05, 2011, 9:23 PM UTC

ajross wrote: post #30

illumin8 wrote: post #24

Earlier quoted context omitted.

The iOS decision was more correct because it has proven itself in the marketplace. Consumers overwhelmingly demand touch interfaces on their smartphones and tablets, as opposed to stylus, trackball, or any other that has come before it. Android started as a platform trying to out-Blackberry RIM. When the iPhone was released in 2007 they switched to a model of trying to out-do iOS.

"Proven itself" how, exactly? Last I checked Android devices were outselling iOS. Now, there's room for argument here about what the proper design is for a mobile OS. But if you're going to support your platform flamage with statements like "Consumers overwhelmingly demand" you need to synchronize the argument with the facts.

"Last I checked Android devices were outselling iOS."

Source? There have been many reports of Android phones outselling the iPhone, but I am not familiar with the ones about Android devices outselling iOS devices (iPod touch, iPad, etc.)

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

#37

Post by wmf » Mon, Dec 05, 2011, 9:23 PM UTC

pace wrote: post #28

Isn't Google's staff working under NDA? I love the open discussion about Android's weakest point and I appreciate opinions from all side, in particular those from inside Google -- but this uncoordinated communication on G+ addressing problems w/o delivering a solution damages Android's image to some extent.

It would be nice if Google could just say "responsiveness: we fixed it" but meanwhile I think these recent discussions are far better than the uninformed trolling that was going on before.

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

#38

Post by zyb09 » Mon, Dec 05, 2011, 9:24 PM UTC

pace wrote: post #28

Isn't Google's staff working under NDA? I love the open discussion about Android's weakest point and I appreciate opinions from all side, in particular those from inside Google -- but this uncoordinated communication on G+ addressing problems w/o delivering a solution damages Android's image to some extent.

How's that heavily damaging? Google is known to be open about its workings, and I think most people agree that an engineer explaining underlying concepts is a positive thing. Putting up NDAs on every little thing is just silly and annoying.

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

#39

Post by rayiner » Mon, Dec 05, 2011, 9:25 PM UTC

interlagos wrote: post #11

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…

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 content a split-second earlier is almost certainly the right trade-off. The user will chalk the checkerboard up to page loading and their internet connection. They'll chalk hiccups in manipulation up to the device itself.

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

#40

Post by marshray » Mon, Dec 05, 2011, 9:26 PM UTC

pace wrote: post #28

Isn't Google's staff working under NDA? I love the open discussion about Android's weakest point and I appreciate opinions from all side, in particular those from inside Google -- but this uncoordinated communication on G+ addressing problems w/o delivering a solution damages Android's image to some extent.

Did you see the part about "I’m interning with the Windows Phone team starting in January"?

Still, I don't have experience with iOS devices, but my Nexus S tends to be so laggy at times that apps crash frequently. (I had attributed it to GC).