Former Google intern explains why UI lag occurs more often in Android than iOS

13567

Comments

  • Reply 41 of 138
    gongon Posts: 2,437member
    Quote:
    Originally Posted by charlituna View Post


    Despite how bad I really hated the few times I had to work in Android because of its 'way more beta than even Siri' feeling, this is an intern who probably has little clue about what the upper boys are thinking in terms of priority. Any perception that they don't care is really just his personal view.



    And I wouldn't really trust him to know what's up in iOS given a lack of any qualifying data like say just the fact that he's written an app for the device.



    He makes some general statements about Google's priorities, but it's on a general level - design and development principles, something every developer working there would know. I don't see where he claims to know "what the upper boys are thinking". He just says "this thing is important, it hasn't been done yet, I think it should have high priority". The comment from the engineer sheds light on the technical obstacles and makes it obvious why it hasn't been done yet.



    If Google considers the issue to be worth the effort at this time, they are probably waiting for the next major OS version or some other time. It would make sense that they collect issues whose fixes require breaking application compatibility, and then fix all of those in one go to minimize trouble for the devs.
  • Reply 42 of 138
    Quote:
    Originally Posted by Gon View Post


    I have heard mentions of it. So has everyone else. That's exactly why you should stop repeating these general statements ad nauseaum. Specifics contribute to the discussion, repeating what has already been said does not. Compare these discussions --



    A: [Specific Android 3.0 tablet] lags in ways X, Y, Z.



    Fair call.



    But really it goes like this



    A) company a and m make operating systems for computing devices

    B) company a makes computing devices

    C) company g collects user data to sell ad space to anyone with a couple bucks



    (4 years go by)



    A) company a and m make operating systems for computing devices

    B) company a makes computing devices

    C) company g collects user data to sell ad space to anyone with a couple bucks



    ...



    As you can see the problem isn't that commenters aren't adding to the debate with specifics. It is that the specifics have nothing to do with device x or interaction p and to debate device/interaction simply muddies the real debate.



    The real debate isn't between a bunch of geeks about their toys. it is about making computers or selling ads. Far as I am concerned if you have a shred of geek about you then it is about computers.



    Otherwise you are a strange person with fevered eyes and loyal fist to chest waving a junk mail providers logo in the air telling us all with much certainty how spam is the future and actually way cooler than computers.
  • Reply 43 of 138
    d-ranged-range Posts: 396member
    Quote:
    Originally Posted by Gon View Post


    Plenty of people (I wager also on this forum) play console games which are fixed to 30FPS, like that Android photo gallery mentioned in the original post, and seem happy even if they have previously owned a proper gaming PC which did solid 60FPS. Then there are Mac owners who watch 24p movies on a 60Hz screen which causes a stutter of similar magnitude once a second. Are all of these people serial liars or blind if they say they don't have a problem?



    Above 30 fps framerate doesn't really matter all that much for perceived smoothness, as long as the framerate is consistent. A consistent 30 fps without any framedrops or stuttering is perceived as MUCH smoother than a framerate that peaks between 30 and 100 fps, which is why capping the framerate by syncing it to 30 or 60 Hz makes sense. PC games also do this. As the (very informative) original article explains, this is exactly why the Android UI feels choppy. Not because it isn't '60 fps' but because the UI performance is not consistent. If you watch cable TV or a movie, do you ever perceive that as 'choppy' or 'not smooth enough' (not considering framerate pulldown artefacts), even though it is usually 'only' 25 fps?



    Choppy and inconsistent UI performance combined with touch input absolutely kills the user experience, because it breaks the illusion of having a 1-to-1 connection between your hands and what happens on the screen. Just imagine using a mouse with input lag on your PC, with an inconsistent and choppy cursor speed and a lag between moving the mouse and seeing the cursor move. Literally NOBODY would accept that.
  • Reply 44 of 138
    gongon Posts: 2,437member
    Quote:
    Originally Posted by cy_starkman View Post


    As you can see the problem isn't that commenters aren't adding to the debate with specifics. It is that the specifics have nothing to do with device x or interaction p and to debate device/interaction simply muddies the real debate.



    Unless you are trying to argue that Google is evil and therefore it is a good idea to make contentless shit-stirring posts on AI, I have no idea what you are going for.
    Quote:

    The real debate isn't between a bunch of geeks about their toys. it is about making computers or selling ads. Far as I am concerned if you have a shred of geek about you then it is about computers.



    How about taking the real debate to its own thread, then? This one is about UI lag in Android.
  • Reply 45 of 138
    Quote:
    Originally Posted by GalaxyTab View Post


    Silly comment.



    First of all, that is a HTC Android prototype, not a Google prototype. Secondly, Android is software. If software wasn't scalable and able to be used on different form factors iOS (which is derived from OSX) would not exist as it does today.



    The earliest Android SDK and prototypes were designed for touch and physical interfaces and Android as it is today is fully usable using a dpad and hardware keyboard.



    Can you provide a source for that information? All Android phones ever shown or talked about pre-iphone were blackberry clones with a keyboard.
  • Reply 46 of 138
    MacProMacPro Posts: 19,718member
    Quote:
    Originally Posted by d-range View Post


    Above 30 fps framerate doesn't really matter all that much for perceived smoothness, as long as the framerate is consistent. A consistent 30 fps without any framedrops or stuttering is perceived as MUCH smoother than a framerate that peaks between 30 and 100 fps, which is why capping the framerate by syncing it to 30 or 60 Hz makes sense. PC games also do this. As the (very informative) original article explains, this is exactly why the Android UI feels choppy. Not because it isn't '60 fps' but because the UI performance is not consistent. If you watch cable TV or a movie, do you ever perceive that as 'choppy' or 'not smooth enough' (not considering framerate pulldown artefacts), even though it is usually 'only' 25 fps?



    Choppy and inconsistent UI performance combined with touch input absolutely kills the user experience, because it breaks the illusion of having a 1-to-1 connection between your hands and what happens on the screen. Just imagine using a mouse with input lag on your PC, with an inconsistent and choppy cursor speed and a lag between moving the mouse and seeing the cursor move. Literally NOBODY would accept that.



    Not my area of expertise but perhaps several things can be animated at once in certain situations and frame rates maybe cumulative across animations thus a cap would produce stuttering whereas the ability go run higher rates wouldn't so much.



    I'd be happy to be corrected if this isn't true.
  • Reply 47 of 138
    MacProMacPro Posts: 19,718member
    Quote:
    Originally Posted by bullhead View Post


    Can you provide a source for that information? All Android phones ever shown or talked about pre-iphone were blackberry clones with a keyboard.



    Exactly. Funny how droidheads quote hardware when it suits them and software when that suits them better.
  • Reply 48 of 138
    We use a Nexus S 4G for our on call phone and I don't see any lag unless it's on a webpage that is also rendering flash. The Android devices we've used here do suffer lag, but nothing to the point where it's like OMG this is sooooooo terribly unusable that I can't wait 1 second for the screen to refresh.
  • Reply 49 of 138
    MacProMacPro Posts: 19,718member
    Quote:
    Originally Posted by GalaxyTab View Post


    Silly comment.



    First of all, that is a HTC Android prototype, not a Google prototype. Secondly, Android is software. If software wasn't scalable and able to be used on different form factors iOS (which is derived from OSX) would not exist as it does today.



    The earliest Android SDK and prototypes were designed for touch and physical interfaces and Android as it is today is fully usable using a dpad and hardware keyboard.



    Love your user name for an Apple blog. That must be like someone using 'HyundaiElantra' on a BMW blog and criticizing the BMWs.



    How's that laggy thing working out for ya?



    Sorry couldn't resist.
  • Reply 50 of 138
    On another note...



    While the kid is trying to make himself sound intelligent and in his mind more employable, I wouldn't touch him with a 1000 ft pole. If I were Microsoft I'd cancel his upcoming internship.



    I would bet that he (at google) had some type of employment contract which prevents him from disclosing company secrets and technologies... And even if google doesn't care, there are a ton of future employers who steer away from this guy.



    Bottom line is, every company has tons of hacked together, or not the best way to do, code... Heck, he may not have even written a line of code. Could've simply talked to his coworkers, find the dirt on the systems, and then blog about it... eh, who needs to run that risk?
  • Reply 51 of 138
    MacProMacPro Posts: 19,718member
    Quote:
    Originally Posted by skyzlmt View Post


    On another note...



    While the kid is trying to make himself sound intelligent and in his mind more employable, I wouldn't touch him with a 1000 ft pole. If I were Microsoft I'd cancel his upcoming internship.



    I would bet that he (at google) had some type of employment contract which prevents him from disclosing company secrets and technologies... And even if google doesn't care, there are a ton of future employers who steer away from this guy.



    Bottom line is, every company has tons of hacked together, or not the best way to do, code... Heck, he may not have even written a line of code. Could've simply talked to his coworkers, find the dirt on the systems, and then blog about it... eh, who needs to run that risk?



    I partially agree on the employer thing but then 'truth will out' as they say and these are pretty serious screw ups he covers. It's not as if everything he says wasn't already known by most on AI it was just nice to see it all on a Google blog for a change.
  • Reply 52 of 138
    Quote:
    Originally Posted by NotRs View Post


    That's exactly my point. They sacrificed quality for a quicker release to compete. Even if they said "oh wow, look at the iPhone... let's go touchscreen!" they should have taken the proper time to do it right. Even if it took longer to ship... they'd have a stronger product today.





    Then again... the strategy of "we didn't do it first, but we did it best" could also be used to accuse them of copying Apple. (not by product but by method)



    I agree with you and Android was obviously a rush job upon release (and suffers from it today) but from a business standpoint I feel they had no choice but to release early in order to even compete against the new juggernaut (Apple)
  • Reply 53 of 138
    gongon Posts: 2,437member
    Quote:
    Originally Posted by d-range View Post


    Above 30 fps framerate doesn't really matter all that much for perceived smoothness, as long as the framerate is consistent. ...



    Yep, I understand all that. I was responding to Apple][ who went and pronounced every Android device in existence is shit due to lag plus other factors. I was (and still am) curious about how this hideous product-destroying lag manifests in practice, e.g. on Galaxy Nexus.



    Comparisons to other video displays were intended for perspective. For instance, I doubt 30FPS cap on the gallery is what makes the Nexus "suck".
  • Reply 54 of 138
    Quote:
    Originally Posted by digitalclips View Post


    This is going to be in the history books! Having been closely involved in the history of this industry since 1978 this is amazing absolutely amazing, you couldn't write a novel as good as this.



    By rushing to copy iOS as soon as Schmidt ran over from his Apple Board seat to spill the beans using their Blackberry copy as a base rather than starting over and ripping off iOS from scratch. It was obviously either a calculated risk based on timing or simply ignorance of what a mess they were creating going the route they did. Lack of any previous knowledge of touch UI most likely means option 2.



    I would love to know who pushed for speed over good reverse engineering Microsoft style? if they'd waited to get their hands on iOS Android would work properly?. My money is on Schmidt who must have become obsessed with doing this before Apple realized his duplicity and asked him to resign.



    What an ironic corner Google have painted themselves into. It's like Windows all over again, it's a total mess but their own success makes it almost impossible to fix due the sheer number of apps that would cease to work if they brought Android up to iOS standards.



    Still waiting for two things from you.



    1) evidence that Schmidt did all that betrayal shit you constantly spew



    2) reasons why Apple and Steve (who are usually litigious) decided to be functionally retarded in this case and allow it to happen without bringing evidence of such duplicitous action to court and pretty much ending Android with one move.



    unless you're suggesting that Schmidt is so smart and Apple and Steve are/were so stupid that they can't do it.



    And I thought you were an Apple fan -_-
  • Reply 55 of 138
    Quote:
    Originally Posted by bullhead View Post


    Can you provide a source for that information? All Android phones ever shown or talked about pre-iphone were blackberry clones with a keyboard.



    Android was built using a JavaVM for a reason...that reason being scalability.



    from its inception Android was meant to be hardware agnostic.



    The BB style prototype is just 1 prototype and not indicative of the general direction for the entire OS.
  • Reply 56 of 138
    Quote:
    Originally Posted by digitalclips View Post


    Exactly. Funny how droidheads quote hardware when it suits them and software when that suits them better.



    how does that follow?
  • Reply 57 of 138
    Quote:
    Originally Posted by digitalclips View Post


    Love your user name for an Apple blog. That must be like someone using 'HyundaiElantra' on a BMW blog and criticizing the BMWs.



    How's that laggy thing working out for ya?



    Sorry couldn't resist.



    he hasn't criticized Apple/iOS/iPhone/iPad/etc ever as far as I can see.



    which is the opposite of what your analogy implies.
  • Reply 58 of 138
    neo42neo42 Posts: 287member
    A friend of mine working for a large and well-known online/mobile game company has griped quite thoroughly about Android's touch lag. However, he has indicated that the main issue they have had to deal with was touch input scan rate, not animation speed or priority. I am thinking that some of the lag issues addressed by the intern can be fixed natively in applications (ie they are only inherently an issue in the native/built-in apps)
  • Reply 59 of 138
    d-ranged-range Posts: 396member
    Quote:
    Originally Posted by digitalclips View Post


    Not my area of expertise but perhaps several things can be animated at once in certain situations and frame rates maybe cumulative across animations thus a cap would produce stuttering whereas the ability go run higher rates wouldn't so much.



    I'd be happy to be corrected if this isn't true.



    Usually all rendering is done to offscreen buffers, which in the case of a UI framework such as on Android or iOS are combined (composited) to some other offscreen buffer, which is put in a display queue until it is swapped to the screen. This display queue can hold 1 buffer (in addition to the buffer currently displayed on-screen), which is called double-buffering. It can also hold 2 buffers, which is called triple-buffering. In extreme cases (wildly varying render times) you could even choose to add even more buffers, at the expense of increased memory consumption (n-buffering). By queuing up rendered frames and swapping them at a certain interval (30 Hz, 60 Hz) you can smooth-out peaks in the rendering time to the point you don't see any difference in framerate no matter how much is going on on the screen. Of course with every increase in the depth of the display queue, you introduce one frame of display latency.



    Obviously, when you cap the framerate but the rendering can still not keep up with the display rate, you wil get framedrops and choppyness, no matter what you try. But you have to remember that generally speaking, you are not going to spend close 1/60th of a second rendering stuff and expect to see 60 fps on the screen, since the CPU which has to supply the GPU with stuff to render also has other stuff that needs attention in between frames. If you get close to 1/60th of a second of rendering time, you cap the framerate at 30 fps, which almost gives you twice as much slack in your rendering times. This way you can render almost twice as much at the same framerate and completely smooth out animation. In practice this looks much better than trying to render as fast as you can, at variable framerates.
  • Reply 60 of 138
    Odd that when Microsoft dominated user experience, nobody was particularly sensitive about "smooth animation" and responsive UIs. And it is still the case that if your CPU time was spent entirely executing kernel threads, even the Windows mouse cursor and keyboard would cease to respond fast enough to even be usable. That was normal for Windows. In contrast, I've run both cores on my Mac to 100% CPU but the UI is still completely responsive, even animations play smoothly. My expectations for the desktop are now set by the Mac. Likewise, I expect my tablets and smartphone to be as fluid as the iPad and iPhone. Why go backwards?
Sign In or Register to comment.