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

111–118 of 118 posts

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

#111

Post by interlagos »

TeMPOraL wrote: post #107
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're an end-use it quickly disappears and is a non-issue. It just isn't a real problem for end users. Yes, it is. When people ask me how I like my new smartphone, I always say to them: "I like the idea behind Android, but it sucks in use; this smartphone is too weak to handle the basic OS, which makes using it terribly annoying for most of the time". Yes, it sucks. There are constant lags in everything from bu…

Even my 1st generation HTC Magic+ had an experience absolutely nothing like what you've described. I don't know what sort of broken device you're in possession of, but it has nothing to do with Android. What is being described generally are trivial framerate deviations while animating the UI, not "30 second" pauses.

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

#112

Post by MichaelGG »

interlagos wrote: post #15
MichaelGG wrote: post #14

Earlier quoted context omitted.

Not quite. For instance, on a Galaxy S II, going to the home screen while in the mail app takes ~2 seconds. Doesn't matter how many times I do it, or even if I just do it in a loop, switching between mail and home. It's probably not even Android's direct fault - I wouldn't be surprised if this is Samsung's horrible software shining through - but it's very frustrating, and I don't use other devices to compare it to.

A big part of the delay on the GS II is the Vlingo voice functionality. Did you know (I ask because many people don't know) that if you tap the home button twice it brings up voice mode? The ability to recognize double clicks imposes a certain floor on the responsiveness of that button. That most certainly does bother me, and I've yet to discover how to disable it so it simply reacts immediately.

Yea, I hate that. It comes up by accident all the time. Good point that it could be delaying it. Samsung incompetence.

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

#113

Post by danssig »

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…

>Android is clearly succeeding despite the lack of UI refinement

I'm not sure Android is clearly succeeding. Samsung, etc. are succeeding. If they switch to a superior OS (Windows?) but keep similar pricing I suspect only a very small core of hardcore Android fans would remain.

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

#114

Post by danssig »

jcizzle wrote: post #19

Pretty close on the iOS stuff: 1. All* rendering takes place on the main thread in iOS. 2. The main thread doesn't always have the highest priority. In fact, its priority level changes throughout an application. 3. There is more than just one reason iOS rendering is so fast. Here are two important ones: a. Animation is actually the basis of the entire rendering system. On desktop Cocoa, the drawing system was a littl…

Do you think games will ever take advantage of this on OSX to start giving Apple an edge? Right now I still have to have a Windows machine if I want to do any gaming.

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

#115

Post by danssig »

catch23 wrote: post #60
interlagos wrote: post #29

Earlier quoted context omitted.

I don't disagree with what you've written, and the relative thing is a problem -- if people feel a bit shameful that their new device isn't as slick as the last generation iPhone, it does hurt love of one's device a bit. That's why Android 4.0 takes big steps in the "be proud to show it off" realm. However to the relative thing, to most smartphone users the things that matter are can I use Facebook, how is the pictur…

I disagree here based on interacting with someone who owns an ipad v1. When this person tried out my samsung honeycomb tablet, she thought it was slower "computer" that hers, even though she's doesn't know the specs of my "dual-core" honeycomb tablet.

This is why Apple is right to not talk about specs. It doesn't matter what your specs are if your actual device is slower.

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

#116

Post by JoeAltmaier »

javert wrote: post #46
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…

has nothing to do with threading, and certainly has nothing to do with "real-time priority" Well, it has everything to do with real-time priority, because in the case of Android, there is a clear priority inversion. That is, what should be considered the highest-priority work IMHO (updating the UI) is being delayed for other lower-priority work. Absent other factors, the technically correct way of dealing with this k…

Agreed, sort of. The problem is, the wrong problem is addressed by operating systems.

What you may mean by "the highest-priority work (updating the UI)" is really "the lowest-latency work". What we perceive as UI quality is the latency of sucessive events - is it smooth, and fast.

But OSs only give us a big hammer to manage this - priority of threads. Which is very indirectly related to latency. E.g. priority inversion, blocking i/o, the stupid habit of putting OS threads strictly ahead of user threads, and on and on, all impact latency in a way the programmer cannot constrain.

Experimental OSs have tried to use latency as the fundnamental scheduling metric. But each time a new mainstream OS is released, lo and behold it's based on stupid old priority.

So let's acknowledge the fundamental fact, that we're not being given the tools to achieve what we need, and everything we do is a workaround that's more or less successful. It all glitches under the right (wrong) conditions, all approaches are hacks of one sort or another.

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

#117

Post by jcizzle »

danssig wrote: post #114
jcizzle wrote: post #19

Pretty close on the iOS stuff: 1. All* rendering takes place on the main thread in iOS. 2. The main thread doesn't always have the highest priority. In fact, its priority level changes throughout an application. 3. There is more than just one reason iOS rendering is so fast. Here are two important ones: a. Animation is actually the basis of the entire rendering system. On desktop Cocoa, the drawing system was a littl…

Do you think games will ever take advantage of this on OSX to start giving Apple an edge? Right now I still have to have a Windows machine if I want to do any gaming.

When it comes to games, OpenGL is still the best option. The animation system works well for moving around interface elements in two dimensions. The animation system does not work well for 3D or when you are modifying the bitmap content of a layer on the screen.

Will OSX ever catch up to Windows for games? Maybe. Some game companies take the approach of writing everything in OpenGL to make it easier to port between systems, writing a layer of native code to support their cross-platform code.

However, some studios use DirectX which is windows-only. The popularity of OSX and iOS will only increase the pressure on game developers (and engine developers) to write code that is easier to port.

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

#118

Post by roflharrison »

marshray wrote: post #40
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).

>Still, I don't have experience with iOS devices, but my Nexus S tends to be so laggy at times that apps crash frequently.

This sounds more like poorly written apps than an issue from the article.

For example if you are scrolling a list view and it slows down to the point of crashing, the application probably isn't caching views or has a memory leak (application authors fault).

If your device gets sluggish and you get miscellaneous force closes I would look for applications with background services that are doing more work than they should be.

Post reply on HN