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

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.

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.

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.

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.

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.
How about taking the real debate to its own thread, then? This one is about UI lag in Android.

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

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.

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

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.

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.

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.

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)

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".

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 -_-

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.

how does that follow?

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.

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)

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.

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?

The vast majority of smartphone buyers seem not to be distracted, as you were.

They usually choose Android phones instead of the iPhone, in the premium-priced category, the value category, and even in the free category.

I think it may have been the LG Prada that inspired them. It was announced before the iPhone.

Wrong again!



He's acting like he's never heard anybody mention anything about what you said - that there are seconds of lag between touch and response when using Android.

He asked for some kind of objective example.

All he got in response was weaseling.

Handwaving is not proof.

Let's see a specific example (or even better, multiple examples) of touch and response being separated by "seconds".

iOS can be "considered to be" a RTOS.

For example, if you consider a horse's tail to be a leg, then how many legs does a horse have? Clue: Abraham Lincoln has the answer.

I've developed for iOS and at a lesser extent Android.

One thing Andrew Munn forgot to mention is that unlike iOS, Android uses a CPU taxing "Garbage Collector" to manage variables.

iOS uses Reference Counting which takes away the task of managing variables from the CPU. Android has to "Garbage Collect" unused data which hogs the CPU till the operation is done.

Makes you appreciate the hard work Apple put into the software from the beginning.

I agree. I have ios5 on my IP4, runs perfect. I also have helped two friends update their 3GS' to ios5. On those, it definitely helped to do a full restore from scratch. What also helps is to uncheck selections you don't need in Spotlight Search. I only need to search Contacts, so I unchecked everything else. Adjusting Notifications, Locations and Push on email and Cloud makes a big difference too. Turn off what you don't use, set mail and cloud to "fetch" if you don't need push. Afterwards, do two consecutive hard-resets to clear the memory caches and you are set. The 2 friends I helped with os5 on their 3GS now have buttery-smooth running smartphones.

You are in good company. About 5% of the computer using public have similar expectations.

Apple invented the touchscreen UI. Android just try to steal it. Jobs was so mad that he would launch a thermonuclear war.

That's just ridiculous. Apple only 'invented' the iOS touchscreen UI. Touchscreens had been around (with UIs underneath them) since the 80's. The HP-150 is likely one of the first personal computers incorporating a touchscreen interface.

Also, despite what many people would like to think, if Google is so desperately trying to steal the iOS UI than why is it so "crappy and laggy"? The UI philosophy is so drastically different it's difficult to understand why people still try to preach that Google has stolen anything at all. Android UI is flexible, customizable and dynamic (themes, widgets, custom launchers, etc). iOS UI is completely rigid and static (no themes, no widgets, one size fits all). The performance problems in Android are in some part related to this fact, as the overhead created in the Android environment is significant.

If you believe what you say, then you must also believe that after inventing the touchscreen UI, Apple failed to patent the touchscreen UI. That, despite Steve proclaiming that they have patented the hell out of the iPhone. Seemingly, you believe that despite attending to many patents on the iPhone, Apple neglected to file for the most basic and valuable one of all - the touchscreen UI.

Fact is, the touchscreen UI was in use for years before the iPhone used it. Fact is, Apple did NOT invent the touchscreen UI. Fact is, Apple copied the use of the touchscreen UI.

Basic facts.

I agree with you that Apple didn't invent touchscreen but, from your own HP-150 Wiki link:

"The screen is not a touch screen in the strict sense, but a 9" Sony CRT surrounded by infrared emitters and detectors which detect the position of any non-transparent object on the screen."

From a business standpoint Apple is off-and-on the biggest company in the world, and they took the time to do it right the first time.

Little late to the comments... Did anyone else immediately flash back to Windows 3.11, 95, 98, and finally 2000 and XP when he was talking about a re-write to fix the issues would require significant legacy support?

The main reasons why 2000 and XP (for their time) was so bloated was because they had legacy support going back to supporting 16-bit applications. Microsoft is slowly learning to let go of this support (although it's still bloated), but if Google goes down this road of supporting older apps then it's never really going to fix any of the current problems because of bloat.

For better or worse Apple has done a great job with managing legacy devices and applications. Sometimes that means forcing dev's to rewrite their apps, but it keeps progress moving forward.

As long as Android vendors put their own GUI on Android it can never be as fast as iOS. The evidence have been there all time. The single core A4 800mhz was only 3-8% slower then Tegra 2 dual core 1ghz. The dual core A5 beats cod core Tegra 3 in almost all tests.

Google have to control the graphic layer to be able to accelerate it with GPU/SIMD/NEON/Altivec. Apple have 10 year experience of accelerating OSX with Quartz extreme.

I think that Googles own "motorola" phones will be the ones that gets all these feautures. Here Google can choose the best SoC (something with PowerVR6) and really spank Apple.
But Apple have a huge advantage since they design their of SoCs with PA Semi. The A4-5 have been best in class even if they where clocked lover. Instead of raw mhz they used better memory bandwidth and NEON. This is also the reason why A5 is 30% larger then Tegra2.

Tegra3 is interesting. I wonder what Nvidias price on they are. The Tegra 3 is almost twice as large as Tegra 2 = it costs more then twice to manufacture. Tegra 2 cost 25 dollar. If Nvidia sells Tegra 3 at that price, they have taken a big hit in profit to gain market share. Something that many companies have done to compete with Apple.

The integrated approach to computers/phones/tablets have always been the best. But it have not been successful longtime because that people like diversity. Google is at a cross road with Motorola mobile. Will they lock up Android more? Maybe do the MSTF way where anybody can manufacture the hardware, but MSFT tells them what hardware they have to use + have a locked App store.

Integrated: Apple
Fragmented: Google
Something in-between: MSFT

You really have to wait 1 second for the screen to refresh ???? OMG!!!

To be fair, the stuttering that is present in Android is a product of the OS continuing to work in the background. If you load a Gallery of pictures and swipe through them, the pictures will continue to load. If you open the Music application and flip through album art, it will stream in as on-the-fly. If you open the browser and navigate to a page, it will load in the background even as you're panning around on the screen.

If you perform any of those operations on iOS, loading (or any background operation, really) is put on pause to deal with user input. The web page in the background would "stop" in operation until the touch input was finished.

I don't like the stuttering Android has, but I understand why it occurs, and I'm very interested in what sort of a solution Google can come up with that allows operations to continue in the background while improving the stuttering that can occur, rather than simply wacking all operations for the input thread.

You should see it on my 3GS then........