OS-Wide OpenGL ES Rendering

Although smartphone and tablets still lag behind the technology we have in modern day PCs by several years, their evolution is a highly accelerated version of what we saw in the PC industry. It took decades to go from the first GUIs to the GPU composited and accelerated UIs we have on the desktop today. Android has made a very similar transition in just three years.

Prior to Honeycomb, the majority of screen drawing in Android was done using its skia libraries. These libraries were almost exclusively CPU based and did very little work on the GPU. Over time Google rewrote key elements of Android to use new OpenGL ES rendering paths instead of skia for screen drawing. We saw the first major transition in Gingerbread where parts of the OS became GPU accelerated, but things like the browser were still being rendered to the screen using skia. Honeycomb was a significant step towards GPU accelerated drawing, and ICS all but completes the transition. The other component is the drawing model, which is completely revamped in 3.x and above. 


From Romain Guy's Android Accelerated Rendering Google I/O 2011 Presentation

Honeycomb based tablets were significantly smoother than Gingerbread devices but even they showed some UI performance issues depending on what you asked of them. We later found out that this was a Tegra 2 limitation, something that would surely contribute to NVIDIA not being chosen as the lead SoC partner for ICS.

Also from Romain Guy's Android Accelerated Rendering Google I/O 2011 Presentation

With Ice Cream Sandwich, the OS, browser and all first party apps are OpenGL ES accelerated. The result is absolutely noticeable. App launches, scrolling and window transitions are all buttery smooth. Web browsing is unbelievably smooth and easily comparable to iOS and Windows Phone at this point.

Third party apps have to opt-into the OpenGL ES rendering path, which will likely require an update for those apps that haven't already done so. Google also provides the handy option of forcing all apps to use GPU accelerated apps and ignoring the opt-in (hardwareAccelerated="true" from the AndroidManifest.xml file). The obvious downside is not all third party apps will work gracefully with hardware acceleration enabled, though most do right now. The Southwest Airlines app, for example, will crash as soon as you try to check into a flight if you force GPU accelerated drawing, and Speedtest.net shows a blur for its line graph of throughput during the test. Google has outlined the draw operations that are unsupported in 3.x and 4.x already, which thankfully aren't many. 

 

While it would be nice for Google to allow GPU acceleration settings on a per application basis, the truth of the matter is that many of them work just fine. Those that don't work are likely a simple update away from getting on board, otherwise they risk obsolesce as more platforms get ICS in the future.

If the sluggish UI held you back from Android in the past, ICS almost completely addresses the issue. I say almost completely because there are still some minor hiccups and a couple of more reasonably sized problems with the OS' responsiveness.


Task Switcher with CPU use overlay (new in ICS) enabled

The biggest issue for me is the delay when operating any of the ICS buttons: back, home or the task switcher. While tapping a folder on any of the home screens results in an instantaneous display of its contents, hitting any of the three ICS buttons just isn't as responsive. There's a noticeable delay between when you hit the home button and when you actually appear back at the home screen. It's a delay that's, at least in my opinion, a bit too long. More frustrating is the delay in bringing up the list of recently used apps. It's less than two seconds but it should be in the milliseconds.

I monitored CPU usage while bringing up the task switcher and saw a small spike in CPU usage (~15%) and an associated increase in clock frequency, but nothing significant enough to lead me to believe we're CPU bound here. If anything I wonder if this is a GPU performance limitation similar to what we saw with Tegra 2 and the app launcher on Honeycomb. Given the incredible resolution of the Galaxy Nexus' display and the fact that we're still dealing with a 307MHz PowerVR SGX 540, it's quite possible that the platform just needs a faster GPU. I'm curious to see how well Tegra 3 will do here.

 

The Android vs. iOS Debate The UI: Holo Evolved
Comments Locked

185 Comments

View All Comments

  • zorxd - Friday, January 20, 2012 - link

    They can have some differences (cache size, memory bandwidth, neon instructions) but the A9 is not an ISA. ARMv7 is.

    Given that it has the same configuration, an Apple A5 behave the same as a TI OMAP4 or a Samsung Exynos of the same clock speed. I beleive nVidia tegra2 lacks the neon instructions so can be slower in some cases. There is an article on Anandtech about this.

    Given that the iPhone 4S is only 800 MHz it is the slowest A9 CPU by far.
  • pSupaNova - Friday, January 20, 2012 - link

    The GPU's on the IPhone uses Tiling so in most GPU rendering tasks it will be a lot faster, However spit lots of Triangles at it and then see how fast it really it is.
  • StormyParis - Wednesday, January 18, 2012 - link

    It's not all about performance, at least if you don't do FPS games. The screen on the Nexus is much bigger than on the 4S for example. For me, it's not about performance at all. I went for the GN for its even bigger screen, and that criteria alone was 95% of my decision, the remain 5% being "... and the rest don't suck", and "has xda-dev support'.
  • humancyborg - Wednesday, January 18, 2012 - link

    Once you start accelerating the entire interface, performance becomes much more significant than just FPS games. There's a reason Apple uses such a gigantic and powerful GPU in their devices, and it's definitely not only for FPS gamers.

    Agree with you on the rest, there are other good reasons to buy this phone, just a shame that they skimped here. I have the 4S, GN and Lumia 800 currently and constantly switch around between them.
  • metafor - Wednesday, January 18, 2012 - link

    It doesn't really take a whole lot of resources to render a 2D interface. Just about any ol' GPU with OpenGL ES 2.0 support will do it.

    About the only thing where the GPU is the limiting factor is rendering 3D games. And even then, most if not the vast majority of games on the market will continue to be written for this level of hardware for at least the coming year.

    Honestly, people take benchmarks way too seriously.
  • doobydoo - Thursday, January 19, 2012 - link

    Actually, you're absolutely wrong.

    In fact, the GPU slowness is cited in this very article for causing slowdowns in situations where no 3D gaming is being done.

    Remember, the operating system as a whole is hardware accelerated, so every thing you do - animations, transitions, task switching, etc are carried out by the GPU. With the higher screen, the speed of the GPU becomes even more relevant.

    The combination of a high resolution screen and a low powered GPU is a bad combination and materially affects the performance of everything you do on the phone.
  • zorxd - Thursday, January 19, 2012 - link

    Do you remember the iPhone 4? Who complained that the GPU was slow? It was much slower than the SGX540 in the Galaxy S.
  • metafor - Thursday, January 19, 2012 - link

    Speculation in an article isn't exactly proof of concept.

    Alpha blending, panning, compositing are very light tasks for a GPU pipeline; it's only a problem when a GPU is TMU-limited. And if it's TMU-limited, it would be obvious all the time.

    I don't think you quite grasp exactly what parts of UI rendering are handled -- or could be -- by the GPU and just how trivial it is compared to rendering a 3D game.
  • trob6969 - Wednesday, January 18, 2012 - link

    What i don't understand is why would samsung give the gn 1gig of ddr2 ram then give it an inferior GPU? But to be fair, Apple is no better. Why give iphone 4s a powerful GPU then give it only 512 mb of ram?! My old-ass og moto droid from over 2yrs. ago had that much!
  • doobydoo - Thursday, January 19, 2012 - link

    As alluded to by numerous posters, including one in this comments section, iOS handles memory usage more efficiently than Android so it doesn't suffer any performance penalty as a result of having less RAM.

Log in

Don't have an account? Sign up now