5,597,138 Members 43,505 Now Online
XDA Developers Android and Mobile Development Forum

Finally REAL info about hardware acceleration, ICS, and the Nexus S.

Tip us?
 
matt2053
Old
(Last edited by matt2053; 4th December 2011 at 02:13 PM.)
#1  
Senior Member - OP
Thanks Meter 299
Posts: 2,059
Join Date: Dec 2010
Location: Clearwater, FL

 
DONATE TO ME
Default Finally REAL info about hardware acceleration, ICS, and the Nexus S.

This is a must-read.

https://plus.google.com/105051985738...ts/2FXDCz8x93s

I gather a couple of interesting things from this: 1) the ICS OTA will be a drastic improvement over the ICS ROMs we have now, and 2) I thought it interesting how Google will actually improve UI smoothness in the Nexus S by turning OFF hardware acceleration in some areas.

This really clears up a lot of misconceptions and wrong information people around here seem to pass around regarding UI speed and hardware acceleration

Sent from my Galaxy Nexus using XDA App
The Following 19 Users Say Thank You to matt2053 For This Useful Post: [ Click to Expand ]
 
Zor Omega
Old
#2  
Zor Omega's Avatar
Senior Member
Thanks Meter 35
Posts: 389
Join Date: May 2010
Location: St. Louis, MO
Good find man, lot of useful info.

From Degobah
 
willverduzco
Old
#3  
willverduzco's Avatar
Portal Administrator
Thanks Meter 2007
Posts: 5,948
Join Date: Apr 2010
Location: ǝɹoɯıʇlɐq, MD̡̳̮̖͖ͮ̎̊̄

 
DONATE TO ME
Utterly fantastic find, and a must-read for anyone concerned with Android UI performance. It's quite ironic that due to that 8-MB per-process memory hit, it's actually faster for the Nexus S to render parts of the UI in software. I wonder if the same driver limitations are present in iOS, since they use PowerVR GPUs as well.

For reference, I am including Dianne's complete post below.

Quote:
Originally Posted by Dianne Hackborn
How about some Android graphics true facts?

I get tired of seeing so much misinformation posted and repeated all over the place about how graphics rendering works on Android. Here is some truth:

• Android has always used some hardware accelerated drawing. Since before 1.0 all window compositing to the display has been done with hardware.

• This means that many of the animations you see have always been hardware accelerated: menus being shown, sliding the notification shade, transitions between activities, pop-ups and dialogs showing and hiding, etc.

• Android did historically use software to render the contents of each window. For example in a UI like http://www.simplemobilereview.com/wp...-home-menu.png there are four windows: the status bar, the wallpaper, the launcher on top of the wallpaper, and the menu. If one of the windows updates its contents, such as highlighting a menu item, then (prior to 3.0) software is used to draw the new contents of that window; however none of the other windows are redrawn at all, and the re-composition of the windows is done in hardware. Likewise, any movement of the windows such as the menu going up and down is all hardware rendering.

• Looking at drawing inside of a window, you don’t necessarily need to do this in hardware to achieve full 60fps rendering. This depends very much on the number of pixels in your display and the speed of your CPU. For example, Nexus S has no trouble doing 60fps rendering of all the normal stuff you see in the Android UI like scrolling lists on its 800x480 screen. The original Droid however struggled with a similar screen resolution.

• "Full" hardware accelerated drawing within a window was added in Android 3.0. The implementation in Android 4.0 is not any more full than in 3.0. Starting with 3.0, if you set the flag in your app saying that hardware accelerated drawing is allowed, then all drawing to the application’s windows will be done with the GPU. The main change in this regard in Android 4.0 is that now apps that are explicitly targeting 4.0 or higher will have acceleration enabled by default rather than having to put android:handwareAccelerated="true" in their manifest. (And the reason this isn’t just turned on for all existing applications is that some types of drawing operations can’t be supported well in hardware and it also impacts the behavior when an application asks to have a part of its UI updated. Forcing hardware accelerated drawing upon existing apps will break a significant number of them, from subtly to significantly.)

• Hardware accelerated drawing is not all full of win. For example on the PVR drivers of devices like the Nexus S and Galaxy Nexus, simply starting to use OpenGL in a process eats about 8MB of RAM. Given that our process overhead is about 2MB, this is pretty huge. That RAM takes away from other things, such as the number of background processes that can be kept running, potentially slowing down things like app switching.

• Because of the overhead of OpenGL, one may very well not want to use it for drawing. For example some of the work we are doing to make Android 4.0 run well on the Nexus S has involved turning off hardware accelerated drawing in parts of the UI so we don’t lose 8MB of RAM in the system process, another 8MB in the phone process, another 8MB in the system UI process, etc. Trust me, you won’t notice -- there is just no benefit on that device in using OpenGL to draw something like the status bar, even with fancy animations going on in there.

• Hardware accelerated drawing is not a magical silver bullet to butter-smooth UI. There are many different efforts that have been going on towards this, such as improved scheduling of foreground vs. background threads in 1.6, rewriting the input system in 2.3, strict mode, concurrent garbage collection, loaders, etc. If you want to achieve 60fps, you have 20 milliseconds to handle each frame. This is not a lot of time. Just touching the flash storage system in the thread that is running the UI can in some cases introduce a delay that puts you out of that timing window, especially if you are writing to storage.

• A recent example of the kinds of interesting things that impact UI smoothness: we noticed that ICS on Nexus S was actually less smooth when scrolling through lists than it was on Gingerbread. It turned out that the reason for this was due to subtle changes in timing, so that sometimes in ICS as the app was retrieving touch events and drawing the screen, it would go to get the next event slightly before it was ready, causing it to visibly miss a frame while tracking the finger even though it was drawing the screen at a solid 60fps.

• When people have historically compared web browser scrolling between Android and iOS, most of the differences they are seeing are not due to hardware accelerated drawing. Originally Android went a different route for its web page rendering and made different compromises: the web page is turned in to a display list, which is continually rendered to the screen, instead of using tiles. This has the benefit that scrolling and zooming never have artifacts of tiles that haven’t yet been drawn. Its downside is that as the graphics on the web page get more complicated to draw the frame rate goes down. As of Android 3.0, the browser now uses tiles, so it can maintain a consistent frame rate as you scroll or zoom, with the negative of having artifacts when newly needed tiles can’t be rendered quickly enough. The tiles themselves are rendered in software, which I believe is the case for iOS as well. (And this tile-based approach could be used prior to 3.0 without hardware accelerated drawing; as mentioned previously, the Nexus S CPU can easily draw the tiles to the window at 60fps.)

• Hardware accleration does not magically make drawing performance problems disappear. There is still a limit to how much the GPU can do. A recent interesting example of this is tablets built with Tegra 2 -- that GPU can touch every pixel of a 1024x800 screen about 2.5 times at 60fps. Now consider the Android 3.0 tablet home screen where you are switching to the all apps list: you need to draw the background (1x all pixels), then the layer of shortcuts and widgets (let’s be nice and say this is .5x all pixels), then the black background of all apps (1x all pixels), and the icons and labels of all apps (.5x all pixels). We’ve already blown our per-pixel budget, and we haven’t even composited the separate windows to the final display yet. To get 60fps animation, Android 3.0 and later use a number of tricks. A big one is that it tries to put all windows into overlays instead of having to copy them to the framebuffer with the GPU. In the case here even with that we are still over-budget, but we have another trick: because the wallpaper on Android is in a separate window, we can make this window larger than the screen to hold the entire bitmap. Now, as you scroll, the movement of the background doesn’t require any drawing, just moving its window... and because this window is in an overlay, it doesn’t even need to be composited to the screen with the GPU.

• As device screen resolution goes up, achieving a 60fps UI is closely related to GPU speed and especially the GPU’s memory bus bandwidth. In fact, if you want to get an idea of the performance of a piece of hardware, always pay close attention to the memory bus bandwidth. There are plenty of times where the CPU (especially with those wonderful NEON instructions) can go a lot faster than the memory bus.
Want something on the XDA Portal? Send us a news tip! - [moderate | film | foto | develop]
The Following 2 Users Say Thank You to willverduzco For This Useful Post: [ Click to Expand ]
 
Award Tour
Old
#4  
Senior Member
Thanks Meter 86
Posts: 1,933
Join Date: Aug 2010
Location: Brooklyn
Skimmed through it but it seems that its a compromise to free RAM but not really to speed up performance. Maybe faster app switching but not scrolling, animations, etc. Hopefully the Galaxy Nexus comes to Sprint.

Sent from my Nexus S using XDA App
 
matt2053
Old
#5  
Senior Member - OP
Thanks Meter 299
Posts: 2,059
Join Date: Dec 2010
Location: Clearwater, FL

 
DONATE TO ME
Quote:
Originally Posted by Award Tour View Post
Skimmed through it but it seems that its a compromise to free RAM but not really to speed up performance. Maybe faster app switching but not scrolling, animations, etc. Hopefully the Galaxy Nexus comes to Sprint.

Sent from my Nexus S using XDA App
1) Faster app-switching IS improved performance.



2) Maybe you skimmed past this part?

Quote:
"A recent example of the kinds of interesting things that impact UI smoothness: we noticed that ICS on Nexus S was actually less smooth when scrolling through lists than it was on Gingerbread. It turned out that the reason for this was due to subtle changes in timing, so that sometimes in ICS as the app was retrieving touch events and drawing the screen, it would go to get the next event slightly before it was ready, causing it to visibly miss a frame while tracking the finger even though it was drawing the screen at a solid 60fps."
 
Award Tour
Old
(Last edited by Award Tour; 4th December 2011 at 05:25 PM.)
#6  
Senior Member
Thanks Meter 86
Posts: 1,933
Join Date: Aug 2010
Location: Brooklyn
Quote:
Originally Posted by matt2053 View Post
1) Faster app-switching IS improved performance.



2) Maybe you skimmed past this part?
Freeing RAM to allow more background processes and faster app switching would mean (app launching) performance that is no better than what we already have. With ICS and the anticipation of HW acceleration, we all wanted BETTER INTERACTIVE performance. From playing around with it on the AOSP build, I can clearly see its faster than 2.3 on that regard. I experience constant app relaunching, much more than 2.3 so maybe that's what Google is talking about. But Google scaling GPU acceleration back because of RAM limitations is kind of disappointing to me but understandable.

Sent from my Nexus S using XDA App
 
peacekeeper05
Old
#7  
Senior Member
Thanks Meter 67
Posts: 821
Join Date: Dec 2010
Location: Velenzuela, Metro Manila
thnx for posting this again. I have read his post a while ago. And it was very informative. I am beginning to understand Android more. And I'm beginning to get more excited with the upcoming ICS update for our phone.
 
matt2053
Old
#8  
Senior Member - OP
Thanks Meter 299
Posts: 2,059
Join Date: Dec 2010
Location: Clearwater, FL

 
DONATE TO ME
Quote:
Originally Posted by Award Tour View Post
Freeing RAM to allow more background processes and faster app switching would mean performance that is no better than what we already have. With ICS and the anticipation of HW acceleration, we all wanted BETTER INTERACTIVE performance. From playing around with it on the AOSP build, I can clearly see its faster than 2.3 on that regard. I experience constant app relaunching, much more than 2.3 so maybe that's what Google is talking about. But Google scaling that back because of RAM limitations is kind of disappointing to me but understandable.

Sent from my Nexus S using XDA App
Yeah, I think the constant app re-launching is exactly what they are trying to fix by limiting the HW acceleration.

There are also several comments from other members of the Android team about how they are regularly blown away by how well the Nexus S Hummingbird processor handles SW rendering, and that it does so with such ease that you won't notice the difference, because it will be a steady 60 fps, and 60 fps is 60 fps to the user.

But the main thing that I think is important to take away from reading the post is that Google seems to know exactly wtf they're doing in this area, and they're doing a lot of work perfecting ICS performance on the Nexus S before they release it. So anyone who has felt disappointment regarding performance of ICS on the Nexus S so far can be assured that their apprehensions are indeed premature, and the Google team is keenly aware of the exact same performance issues that have been noted in this forum.

Plus they want it perfect on Nexus S because that seems to be the phone most Googlers personally own and use
The Following User Says Thank You to matt2053 For This Useful Post: [ Click to Expand ]
 
peacekeeper05
Old
#9  
Senior Member
Thanks Meter 67
Posts: 821
Join Date: Dec 2010
Location: Velenzuela, Metro Manila
Quote:
Because of the overhead of OpenGL, one may very well not want to use it for drawing. For example some of the work we are doing to make Android 4.0 run well on the Nexus S has involved turning off hardware accelerated drawing in parts of the UI so we don’t lose 8MB of RAM in the system process, another 8MB in the phone process, another 8MB in the system UI process, etc. Trust me, you won’t notice -- there is just no benefit on that device in using OpenGL to draw something like the status bar, even with fancy animations going on in there.
good enough explanation for me. So we can expect a better performing ICS for our nexus S. I am always pissed on how my nexus running on an alpha ICS rom can have a very very slow and painful app switching.
 
Award Tour
Old
#10  
Senior Member
Thanks Meter 86
Posts: 1,933
Join Date: Aug 2010
Location: Brooklyn
Quote:
Originally Posted by matt2053 View Post
Yeah, I think the constant app re-launching is exactly what they are trying to fix by limiting the HW acceleration.

There are also several comments from other members of the Android team about how they are regularly blown away by how well the Nexus S Hummingbird processor handles SW rendering, and that it does so with such ease that you won't notice the difference, because it will be a steady 60 fps, and 60 fps is 60 fps to the user.

But the main thing that I think is important to take away from reading the post is that Google seems to know exactly wtf they're doing in this area, and they're doing a lot of work perfecting ICS performance on the Nexus S before they release it. So anyone who has felt disappointment regarding performance of ICS on the Nexus S so far can be assured that their apprehensions are indeed premature, and the Google team is keenly aware of the exact same performance issues that have been noted in this forum.

Plus they want it perfect on Nexus S because that seems to be the phone most Googlers personally own and use
I don't know about you but third party apps with hardware acceleration on is visibly more smooth than the same app on 2.3. Night and day difference. I wonder how much of it they're scaling back. Its too bad that you can't easily upgrade RAM on a phone.

Sent from my Nexus S using XDA App

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes