Nexus 7's Project Butter UI smoothness captured on high-speed camera | Hacker News Reader

Nexus 7's Project Butter UI smoothness captured on high-speed camera

techreport.com

62 pointsgeoffgasior34 comments

Much has been made of the Project Butter UI smoothness enhancements built into Android 4.1 Jelly Bean. We've captured them on a high-speed camera and compared the results to a couple of ICS tablets.

Open articleView on HN

The smoothness is a huge improvement, but touch-latency and scrolling physics are still huge problem areas, even in Jelly Bean on Nexus 7 hardware.

In testing, I've enjoyed the Nexus 7 form-factor, but the iPad's responsiveness and scroll behavior are such a relief when I switch back. It was immediately noticeable, even when beta-testing an app on my old iPad 1 today.

These sorts of problems are why, after owning two Android phones I switched to an iPhone 4. I don't even care for apple that much (Linux user).

"Relief" is a good word for what I felt.

And what it shows is investment.

There should be rock solid high performance graphics drivers for every Android phone. There aren't. The chip manufacturers aren't helping because they won't let 'regular' people get access to real documentation, Google isn't helping because it won't put 4 or 5 engineers on it full time. ODMs don't do it because if Google doesn't do it why should they, they take the crappy vendor supplied driver and run with it.

So far there is no penalty to a chip vendor for having crappy video drivers. This is an area where nVidia invested in strongly to win the PC hardware space but has not done squat in for the Android space, at least it isn't visible outside nVidia.

The Nexus 7 is the first Android tablet to even kinda sorta look like the way the iPad moves. This is something that totally confounds me about Google's internal process.

Speaking as an ex-GPU driver guy, you're off by an order of magnitude about the number of engineers it takes to make a solid graphics driver. For a good GPU driver that makes smart choices about display, power management, OGLES, etc, you're looking at 30-40 people, not 4 to 5. Multiply that by every chipset for Android available (NVIDIA Tegra, ARM Mali, Qualcomm Snapdragon, Imagination PowerVR, Samsung Exynos assuming they build their own GPU eventually), and it's prohibitive to do that all within one company. It's also harder for Android than iOS because of the architectural diversity within the Android GPU market. Optimizing for a TBDR like PowerVR is different than optimizing for a standard renderer with a Z-buffer. iOS can make a bunch of assumptions that Android can't due to dependence on a single vendor.

This is a company that just put $3.5 billion dollars of free cash flow into the bank for one quarter [1]. Lets say we pay each of these 40 people per architecture $250,000/year and we do it for 10 architectures. That is $100M in Salary. Lets say they each burn another $250,000 a year in benefits, extra 401K perqs, their own cafeteria with a chef that does special orders. Maybe that doubles the cost to $200M/year So let's buy them all a house as a sign on bonus if they get this done in 5 years or less, in the Valley that is 1 to 2M$ each for 400 people, call it 800M$. So 5 years of epic salary, a house free and clear, and 5 years of effort comes to about 1.8 billion dollars. One half of one fourth of the years annual free cash flow, so a bit more than 12% of the annual free cash flow.

In my opinion that is the difference between investing in something strategic and 'hoping it will be great.'

[1] http://investor.google.com/earnings/2012/Q2_google_earnings....

EDIT: Never do math when your typing quickly.

> so a bit more than 12% of the annual free cash flow

You made it seem like such a reasonable thing to do.

Microsoft doesn't have its own team to write its own GPU drivers. They have conformance tests for third parties and meaningful penalties for drivers that don't conform (no automatic installing, etc). That's the model you should be thinking about, not iOS.

Microsoft is (or at least used to be) pretty smart in how to partner. Reminds me of that Steve Jobs quote along the line of "I wish we were as good at partnering as Microsoft". I'm curious whether their new strategy (basically copying Apple and go vertical) will work out. If it does, we're definitely in a new computing era where commodity devices with highly compatible software is a thing of the past.

1.8 billion dollars in cost. And the better driver is going to return how much of that investment?

That is a great question. And I think the wrong one. But let me share my reasoning and you can tell me if you agree with that or not.

My reasoning goes like this, if you believe the smartphone and tablet is how people will be consuming the types of services Google would like to offer (Search, Social, Etc) then Google needs to be able to deliver and innovate in that market. If the market leader in devices is hostile to Google, then Google needs to either enable a new leader that they can control or be the new leader. Android's strategy of being open has been excellent at acquiring hardware partners but it has not been able to compete in terms of user experience. Apple has demonstrated for three generations (3G, 4, 4S) that user experience dominates the smartphone decision. And the user experience is dominated by graphics and graphics performance.

I don't think three years ago Google could have appreciated just how much the impact that solid graphics support would have in consumer's minds, but now it seems painfully clear to me (and other bloggers who do these types of articles and Anandtech Etc etc) that this part of the equation is key.

I claim that if Google's Android can nearly match Apple software feature for feature in Smartphone OSes, but they don't have a hardware partner that can deliver graphics performance. So by the same reasoning that said "we need to create an OS for smartphones that we're able to compete with" they should now know that "we need to create the complete platform that enables a competitive user experience." The biggest and most stubborn nail sticking up from that problem is effective, high performance, graphics drivers. What is perhaps more important, the emergence of the tablet as a viable platform makes that problem stick out more.

So Google spends 1.8 Billion dollars over 5 years, and as a result goes from having Android devices being 1/10th to 1/8th the market for tablets to being 1/2 or 2/3rds? If they achieve that objective then yes, the rate of the return for that investment will swamp any other use of that money.

The 'do nothing' strategy of having that 1.8B$ sit in cash and cash equivalents for the next 5 years looks to return less than 250 M$ (with at most a 5% annualized rate of return in the kinds of securities they would hold it in)

Makes it look like a simple call from the outside, I completely recognize that it is painfully hard for at least one member of the OC [1] to spend like that, and they've had way too much say on how money was spent for the last 5 years.

But the reason I think it is the wrong question, is that once you start thinking about it in rates of return your value system is dollars for dollars. I think the right question would be to ask "Is there anything holding back the growth of Android that only Google with its resources (cash, brainpower, etc) can fix?" And I think the answer to that is yes, this one.

[1] The "OC" or "Organizing Committee" is Google's equivalent of the 'executive staff' or the 'executive management group'

I think we half-agree on this one. I didn't mean what ROI Google will have strictly in terms of dollars, mindshare/market share/etc are all great to have. However, I don't think that great graphics drivers are as important as you think.

It seems to me that Google can (very cheaply) pick the low-hanging fruit in graphics performance and get 80% of the way there, and then see what they need to do. Also having a "Google" line of devices is very beneficial, as it can be the high end of the Android offerings. I'm typing this reply on a Galaxy Nexus, and I find the phone much better than an iPhone by far (in general, not just in performance, I haven't used an iPhone recently and don't remember how responsive my 3G was).

There's also a false dichotomy in your post that I need to point out. You say that the money will either go to a graphics driver or will sit in the bank, which is trivially false, as Google can invest it in many other ways.

Fair enough. To your last point, this is weak rhetoric but in this case its also a financial tool that is commonly employed to determine rates of return. The comparison is made between investment 'X', and keeping the money around during the time X would be implemented (the 'do nothing' option). It tries to capture the opportunity cost.

To the 80% question, my claim is that this is exactly what Google did, they got 80% of the way there and in phones that worked. In tablets however the additional screen real estate magnified this weakness in graphics below the 'good enough' threshold. It was great that the Nexus 7 made great strides in this area, the Nexus 7 is manufactured by Asus (which made the Transformer Prime, and now the Transformer Infinity) that the graphics did not improve until Google made it the 'Google Nexus 7' (which sounds like they drove more of the decisions) was a problem for the Android ecosystem in general.

My thesis is that 'fixing' it so that Asus and anyone else can build a fabulous graphics experience on Android is possibly the best investment they could make.

30-40 people? How can you get anything done with that many people? Teams of 5-10 people have built entire operating systems. What makes a video driver so complex?

GPUs do a lot more in mobile today than probably occurs to you off the top of your head if you're not extremely familiar with them.

First of all, you have to worry about the actual act of running OpenGL ES applications. This is a non-trivial API with lots and lots of performance tuning required, and don't forget you need a GLSL compiler (which in turn is not trivial at all).

Now, you need to support video decoding. Usually GPUs accelerate this in some low-power way for common formats (H264, etc), so you need to jump through a lot of software hoops to support that for various formats and such. Also, don't forget to add support for HDCP (also not trivial) and content protection throughout your video pipeline, because if you don't, you will be flayed alive by the content cartels.

After that, you need to optimize for power. This turns out to be way more software intensive than you think because a lot of times software has to make the call about whether to pick super-low-power but high-latency mode X or higher-power but lower-latency mode Y. This is also probably where you handle a lot of thermal runaway style cases.

Finally, throughout this entire process, you have to be making sure that everything works. While you're writing the software to get things up and running, any bug you hit in SW could be indicative of a hardware bug. When you do hit something that looks like a hardware bug, it's not like you say, "oh hey let's break out the debugger and see what's up!" A relatively easy hardware bug at this stage of development still probably takes on the order of a few man-months, and a hard one takes well over man-years and millions of dollars (find very short repro case, root cause, investigate software workarounds, design ECO, verify ECO, kick off a new spin).

These are the bare-bones you-can-possibly-be-a-player-in-the-market requirements; how well you do optimizing these various cases will determine how well your chip can do in the market.

How about they target just one chipset, then. Once that one is a lot faster than all the others due to driver quality no one will want to buy phones using the other chipsets until they have faster drivers. People wouldn't have to be technical either - gadget reviewers and early adopters will highlight it for them. Games might only support the better chips or at least recommend them, etc. So eventually no phone manufacturers will use those chipsets until they have faster drivers because people just won't buy their phones. So the chipset people will have to raise the quality of their drivers in order to compete.

This isn't very different to what happened in the PC market over time. Remember how many graphics card makers there used to be before things settled around ati and nvidia?

What might also happen is that the gpus will start to behave in a similar way, giving you some of the advantage that iOS already enjoys. Kinda like directx or certain "standard" opengl extensions.

Android probably doesn't need 100 completely different chipsets. Some number higher than 1 is probably ideal for innovation and competition, yes, but it is obviously inevitable that not every player will survive in the long run anyway.

I suspect that without Google's intervention nvidia will probably win on driver quality in the long term because of their experience in their area along with tegra's current momentum. But you never know - as it becomes obvious that driver quality affects sales some of the other players might catch on in time too.

It looks like this sort of thing is already happening. Phone makers are bringing out less new models per year, there are fewer chipsets being used, android is getting better and better, the android-reskins that phone manufacturers do are getting more minimal... I suspect it will sort itself out in time.

iOS devices use the same PowerVR GPU family as many (most?) Android devices. Is there evidence suggesting they did their own driver? I guess one could tell by comparing what kind of GLES bugs exist in iOS vs Android.

edit: seems Apple's docs refer to Imagination's web site for GPU programming details, which would suggest they're using imgtec's driver. (http://developer.apple.com/library/ios/#documentation/3DDraw...)

And when Apple does there own drivers for laptops they're often worse than the vendors own, as can be shown by rebooting into Windows.

That's not true. The graphics hardware vendors do help (we have a well-staffed team of dedicated Android driver engineers, much more than your 4 or 5) and we work directly with Google's myriad Android graphics engineers. The drivers are as stable and fast as we can all make them, given Android's architecture and the timescales involved with Android releases and customer hardware releases.

I wonder how much of this is hardware versus software. Keep in mind that end-to-end latency has a number of possible sources:

- touch digitizer - CPU to do something with the input - GPU to start rendering the result - display to show the change

In particular, I worry about the first and the last. Apple can get away with using extremely high cost parts in the iPad due to vertical integration (look at the physical size of A5X, for example), whereas Android vendors generally can't. Considering that CPU and GPU are generally selling points whereas touch digitizer performance and display response time are not, it would be tempting for a margin-sensitive OEM to cut corners on those two things.

There is plenty of precedent for this: look at the grey-to-grey response time of the original Xoom.

I always assumed that it was the level of abstraction required for Android to be able to function on a wide variety of hardware. iOS on the other hand is running on a relatively tiny number of devices with hardware chosen for use by themselves.

Even with a difference in milliseconds you'd still be able to discern between "smooth" and "not smooth".

High (but not really [1]) film of a UI doing nothing interesting, with no useful conclusions and not even a side-by-side comparison? How is this useful information in any way?

[1] http://www.ted.com/talks/ramesh_raskar_a_camera_that_takes_o...

As they say at the end of the article, what will really be interesting is to compare this to high-speed camera footage of an iPad doing a similar series of transitions. The fact that they're saying it feels like iPad-esque smoothness is a massive win for Android users.

While the animations are smooth, it still seems to have higher latency following finger actions than the iPhone, and when scrolling it moves the viewport by two pixels at a time as opposed to one (which makes it feel quite un-=smooth in practice).

That's because they're doing vsynced triple buffering system-wide now. Apparently they couldn't get the smoothness without it - which blows my mind, personally, but that's what I was told.

Triple-buffering is only used in cases where rendering a frame takes longer than the vsync period; the first buffer is shown (again) for the second vsync period, and then the second buffer is displayed (assuming it's ready) for the third vsync period, and while the second buffer is being displayed, the third buffer is rendered, and displayed after that.

In cases where rendering is always faster than the vsync period, the third buffer will never be used.

https://developers.google.com/events/io/sessions/gooio2012/1...

Is it really-system wide? I've compared Galaxy Tab 2 10.1 and Nexus 7 side by side. Android UI seems smoother and more responsive on Nexus 7. But there is no difference in page scrolling in Chrome browser. Still lagging.

Am I the only one who neither finds this particularly responsive or fluid?

To be honest, a comparison with an iPad would have been really nice, as people seem to think it's quite responsive.

So far I have failed to see how the iPhone UI is much faster than Android.

Maybe it is because I only care about high end Android devices?

Possibly. Take a shot at a Galaxy Spica. It's an atrocity.

It is a 2009 model and I never saw it on sale in Germany.

Likely. But highend android models actually have more horsepower than the apple alternatives.

They do really need it though. Because on iOS with truly native code and a static hardware stack, they can just push more performance. The same is true when comparing consoes with desktop pcs. Many games actually run slower on more powerfull hardware, just because of all the extra levels of indirection.

> Because on iOS with truly native code and a static hardware stack,

Yeah, Apple can get away with it, because of the single architecture.

Even with Java Google could have decided to target native code generation ahead of time, instead of using a JIT.

Doing so enables the distribution of single binaries which can be optimized for the large spectrum of Android mobiles.

With native code you need to produce binaries for each set of hardware architecture you want to support.

This is (to me) a weird way to evaluate smoothness. By slowing it down, the default space between the frames is larger. So it seems like minor glitchiness is going to be harder to catch, not easier.

Reply on news.ycombinator.com