Database Users

How to improve Android GUI experience

I hope this isn't perceived as spamming or fishing for votes. I think most of us would like to see a smoother Android GUI instead of that choppyness on our 1GHz phones. I and many people believe that Google can do something about this but are not prioritizing this as they should. I think we can change this by visiting and voting here, clicking on the star under the headline, if we want to see a change: http://code.google.com/p/android/issues/detail?id=6914
Who knows, if we start voting now, maybe they will implement this feature in the next Android version.
P.S. You need a Google account to be able to vote.
EDIT: Maybe this is why we haven't seen it yet?
From what I've heard, the fault lies mostly with HTC, encouraged by wholesale indifference by the carriers. Here's the story I was told:
* Qualcomm makes the core chipset used by most HTC phones, and most Android phones were built by HTC until VERY recently. Thus, the things that got the most attention during Android's first year and a half of commercial availability were things directly supported by HTC phones.
* The price charged by Qualcomm for its chipset varies, depending upon what features the handset manufacturer chooses to license from them. Put another way, every Qualcomm chip in a given family has the silicon resources to do everything... but manufacturers are only allowed to use the features they pay Qualcomm for the right to use.
* Because the carriers don't care, and the carriers are HTC's real customers, HTC didn't care about GPU support, either. It saved a few cents per phone, and washed its hands of GPU support to boot.
* Making matters worse, Qualcomm only makes its chipset documentation available under NDA (at least, the parts dealing with "premium" capabilities), and only made it available to licensees (of which there were very, very few). Ergo, the documentation has been VERY hard to come by, and less likely to be leaked by a public-minded HTC employee for the good of humanity.
Put another way, there probably isn't a thing Qualcomm can do to stop the folks at xda-developers.com from releasing guerrilla video drivers for HTC Android phones that take advantage of acceleration if they can figure out how it works, but you'll never see a phone come out of the box new with GPU acceleration unless HTC officially licenses the capability from Qualcomm. Nor will you see Google making it easy to do an end-run around the official release to graft it on, because then Qualcomm would sue THEM.
Click to expand...
Click to collapse
- This is from: http://androidforums.com/android-news-talk/29584-why-doesnt-androids-gui-use-gpu-acceleration.html

I starred it.
Definitely is bizarre that GPU integration isn't enabled in Android 2.1+

This hardware-can-do-qualcom-wont-allow-it is old...
It happens with a LOT of devices...
Sent from my HTC Desire using XDA App

I'm glad to see that we are climbing on the chart of issues.
I have come to notice that the issue of the choppy Android experience is not only a problem because of the lack of GPU acceleration. Android phones tend to respond to our gestures way too exactly. This results in uneven transitions, one half of the animation is fast and the other half is slower. This unevenness being a result of us not making, or following through, with perfectly even movements in terms of speed. I believe this is something Apple has addressed and they did it very nicely because even though you are moving your fingers unevenly and slowly, the UI transitions follows your finger in an even and smooth fashion but in a speed that matches your finger. This looks phenomenal. Same goes for faster input gestures, the Ios (iOS) responds in an even and smooth fashion but the transition is faster.

It was the same with my old HD1, the xda gpu-drivers helped alot. Looks like we'll have to take the matter into our own hands again.
Wasn't HTC mass-sued for this a while back?

Syc said:
It was the same with my old HD1, the xda gpu-drivers helped alot. Looks like we'll have to take the matter into our own hands again.
Wasn't HTC mass-sued for this a while back?
Click to expand...
Click to collapse
Nope. There was a whole load of talk of it over the TyTn II debacle, but the only thing to ever come of that was the rather excellent XDA GPU drivers.

I hate to admit this, but if Google, or whoever it is responsible, doesn't do something about this, I'll have to look elsewhere (Iphone). It might sound crazy but it's that important to me. I mean, it's so basic. Why add mega-ultra-fiction features and all other sh*t, when you don't know how to make a smooth transition. The basic element of the GUI.
Don't get me wrong, I don't like Apple, their policy or their attitude towards the rest. However, I'm being honest about this: they care. I haven't seen one Android phone capable of delivering smooth transitions although they are more powerful than the Iphones. On the one hand you have a team utilizing the entire potential of their sh**ty phones, and on the other hand you have a team doesn't give a rats a*s about the hardware in them.
I don't know if Google is to blame or the phone manufacturers. I just don't like the idea of owning a 1 GHz CPU and an awesome GPU (Samsung Galaxy S) and not being able to use it.

Sorry to bump an old thread.
Has there been any progress on this issue?

Using spare parts and setting all the window animations and transitions to very slow has made everything "smoother" to me for all purposes of discussion. during the slow but smooth transition, my phone has time to fully load the next screen or popup menu, therefore it all appears to happen seamlessly.

android is very smooth on my Hd2 ... Did you try a cyanogen mod build ?

Sorry, i was referring more towards the GPU being actively used by the UI front end.
Im using a Legend with Azure's cyanogen mod (froyo) things are pretty slick but I can tell when there are slowdowns, but the worst offender is definately the web browser.
The best example I can find is going to the html5 test website, I get a score of around 180 and the iphone about 140, but the legend browser (built in and Dolphin) really struggles to scroll that page, whereas on the Iphone its extremely smooth. Its these kind of inconsistencies which are annoying.
Another gripe is the whole portrait-landscape switch, its not gpu based in the least and its a rather half assed solution at the minute (visually). But I understand that no app could ever interfere with how this works as its so deep in the os? Such a shame.
I work in animation which is why im overly critical

[Q] UI responsiveness not quite up to par--why?

I haven't seen any posts commenting on this issue too directly. I played with the Xoom in the Verizon store and noticed that although the UI animations were pretty smooth (with the exception of the app list fly-in, the rotation, and the page-turning in the reader, which all had a little frame stutter), the touch responsiveness in general still just wasn't quite up to par with the Ipad. When scrolling through homescreens there's a small but noticeable delay before the screen actually starts to scroll, whereas with the Ipad the scrolling seems to begin instantly. The Xoom is similar in feel to the Galaxy S phones, which were smooth but not quite as responsive as IOS, whose instantaneous responsiveness just inspires more confidence when you're navigating the device.
Ultimately it's a small difference but one that makes a big difference in the perception of the device's responsiveness. Is this a hardware or software issue? If Honeycomb finally has hardware acceleration, why are IOS and WP7 still ahead in this department? Is it because Android's more complex homescreens require more power to scroll? Is this due to something inherent in Android and Java? Is it possible that a future Honeycomb update might fix this completely? If someone with some expertise in the subject can comment on this, I'd really appreciate it. I fully expected Honeycomb to kill any complaints people could have about UI responsiveness, but it just doesn't seem to have happened yet, and I haven't seen any thorough explanation for it. Thanks a lot.

I just pulled out my Xoom and tested each of the things you talked about.
Auto rotation is slower than my phone.
Everything else is instant... though I have not used the reader. I have noticed stutter in the Kindle app.
But in the main UI, scrolling home screens and app list fly in is instant.
I have head of the auto rotate complaint and Kindle page turning complaint in other comments in this board and others... but the main UI? Nope.
I do not know what was the situation with the Xoom in the Verizon store, but in my personal usage the problem you describe does not exist... I think if it did on a wide basis, you would hear about it.
Describing something as a Hardware vs. Software issue in this case is non-productive. In every instance you can start with the hardware and say if it had more "oomph", you can often make a problem go away. Most issues like this can be dealt with in Software. The only time the whole thing is problematic is if the hardware is so underpowered in relation to what the software is trying to do. My guess is these things that are definitely happening (rotate, slow page turn) can be fixed in software, especially on this hardware.
My experience on the Android platforms is future updates fix first release issues.
My experience is also that extending future OS versions to hardware that cannot support them can be problematic, but Apple has experienced the same issue.

I have to agree that this is not as quick as I thought it would be.
I am blaming it on an app maybe, so I am removing everything back to stock.
The app list fly in is the worst. Looks better on my evo.

hctarks said:
I haven't seen any posts commenting on this issue too directly. I played with the Xoom in the Verizon store and noticed that although the UI animations were pretty smooth (with the exception of the app list fly-in, the rotation, and the page-turning in the reader, which all had a little frame stutter), the touch responsiveness in general still just wasn't quite up to par with the Ipad. When scrolling through homescreens there's a small but noticeable delay before the screen actually starts to scroll, whereas with the Ipad the scrolling seems to begin instantly. The Xoom is similar in feel to the Galaxy S phones, which were smooth but not quite as responsive as IOS, whose instantaneous responsiveness just inspires more confidence when you're navigating the device.
Ultimately it's a small difference but one that makes a big difference in the perception of the device's responsiveness. Is this a hardware or software issue? If Honeycomb finally has hardware acceleration, why are IOS and WP7 still ahead in this department? Is it because Android's more complex homescreens require more power to scroll? Is this due to something inherent in Android and Java? Is it possible that a future Honeycomb update might fix this completely? If someone with some expertise in the subject can comment on this, I'd really appreciate it. I fully expected Honeycomb to kill any complaints people could have about UI responsiveness, but it just doesn't seem to have happened yet, and I haven't seen any thorough explanation for it. Thanks a lot.
Click to expand...
Click to collapse
I'm not finding the same issues you are. The orientation delay is 100% intentional. I wish there were built in options that let you mess with the delay, but that will happen soon enough. I don't mind or notice this intentional lag in daily use.
I'm not finding any other lack of smoothness. I've played with iOS on many different devices, and I find my Xoom to be just as smooth. The iOS devices were smoother than my Droid X (always have been smoother than my phones), but I like what powerful hardware mixed with Honeycomb has shown me.

I'd certainly love to be wrong about this. Maybe it was the display unit that was faulty. But even though the homescreen scrolling was perfectly "smooth," it was more the delay in response that bothered me. When I set my finger down and swiped from one screen to another, there was always a very short, split-second delay before the screen started moving, which felt as if my finger was "slipping" for a few millimeters before gripping the homescreen. This probably isn't even something that I would have noticed if I hadn't been comparing it side-by-side with the display-unit Ipad, which, in comparison, seemed to start scrolling without even the tiniest delay, which ultimately gave the Ipad app list a more authentic sense of tactility.
It looks like Bielinsk is having a similar experience, so we know this isn't a completely isolated phenomenon. Maybe both Bielinsk's and my experience had to do with the specific units and installed apps, but even the possibility that installing a certain app can degrade the whole UI experience on Honeycomb seems to be a problem that IOS is less prone to. I've also read reviews, such as the one on Anandtech, that note that smoothness in Honeycomb is improved but not quite at IOS-level. Again, I hope I'm wrong. Everything else about Honeycomb seems fantastic, but the not-as-responsive-as-IOS issue just seems like something that Android can't fully shake.

Bielinsk said:
I have to agree that this is not as quick as I thought it would be.
I am blaming it on an app maybe, so I am removing everything back to stock.
The app list fly in is the worst. Looks better on my evo.
Click to expand...
Click to collapse
Please update us on whether wiping fixes the problem for you.

I uninstalled all the apps that are not Tablet apps and have the same issue.
Removed all widgets, except the clock.
I don't see any delay or pause changing home screens, but the app fly down list just really looks like ****. I put on spare parts and turned the animations to fast to see if that would help and it didn't see to do anything.

Actually the app fly-in frame-stutter was something that I first thought I noticed when Google demoed the tablet at their Honeycomb event. And then it seemed confirmed when I tried it myself at the store.

Yea, I noticed that when I played with one at Costco. I couldn't really tell if it was designed to look like that or not. I remember everyone raving during the Xoom's debut at CES about how smooth it was and using the app fly in as an example of said smoothness. Weird.

I think the lag and less responsive than expected phenomenon is absolutely real and undebateable even if some have not experienced it. We've seen it many times in online reviews and I have personally experienced it on demo units in store.
What it comes down to is development. Combinaton of hardware and software.
Although the experience is optimized on Android, it is prioritized on Apple.
That is the key idea you need to understand and unless the hardware and software BOTH prioritize it, Apple will always win here since they control both hardware AND software.

DatterBoy said:
That is the key idea you need to understand and unless the hardware and software BOTH prioritize it, Apple will always win here since they control both hardware AND software.
Click to expand...
Click to collapse
Well, but then you look at the fluidness of WP7 devices for which the hardware is made by companies that aren't Microsoft, and this argument doesn't really seem like the whole story.

I love my xoom, so this is not a complaint, but the device is not as smooth as I expected it to be. I have an og droid running one of the cm7 builds and overclocked to 1.2ghz. It is a much smooter device than my xoom in many situations.
I do not experience lag on my home screens or when using widgets, but the app fly in is crap and the browser scrolling is laggy. It was this way when I purchased it so I do not attribute it to any apps in particular. I just think honeycomb is in need of some coding polish.
Really makes me wonder if the dual core is being used for anything aside from keeping the CPU in a lower state of energy consumption for battery life. I wish there was some sort of widget that could show CPU usage so that I can see what is making use of the hardware and what is not.
Sent from my Xoom using XDA App

This is depressing. I really don't understand how it's possible that a hardware-accelerated version of Android on a dual-core device can be, in certain UI animations, consistently laggier than non-hardware-accelerated versions of Android on certain single-core phones.
Edit: For example, the app drawer fly-in on a Samsung Vibrant with a custom ROM or just Launcherpro is extremely smooth--seems like twice the framerate of the same animation on any other Android phone I've seen.

I have 100% the same thoughts/experience, I bought this on day 1, and when I had it up with zero apps it was throwing me similar lag to what has been described so far - the experience just isn't smooth or polished.
The f'd up thing? We basically have to rely on groups like CM (who I love!!!) to make our exerperiences closer to what we expect, I think we can all agree that once/if (PLEASE!) the CM crew starts building custom ROM's for us it'll be optimized and if it still runs like this, that's proof (in my eyes) that something is seriously wrong with this platform.
Fingers crossed we see some kind of update soon... Either official or non.

hctarks said:
... But even though the homescreen scrolling was perfectly "smooth," it was more the delay in response that bothered me. When I set my finger down and swiped from one screen to another, there was always a very short, split-second delay before the screen started moving, which felt as if my finger was "slipping" for a few millimeters before gripping the homescreen. ...
Click to expand...
Click to collapse
I think this is actually by design. This prevents screen movements when one touches the screen for whatever reason and moves slightly, but does not intend to slide the screen, preventing screen jitter. In testing, the slide amount is something less than a centimeter.
I'm trying to decide if I would turn it off or leave it on if it could be toggled.
I'm interested if alternate desktop app's would do this.
So, it is like the orientation delay that is apparently by design. I wish my phone had that, if flips a little to easily (vibrant).

I think IOS demonstrates pretty adequately that such a touch-response delay is not necessary. Same goes with, I think, orientation-switch delay. Re: the latter, when it's a problem on a device it seems like it's usually due to the threshold for the switch being set too low--not the responsiveness of the switch, which I think should happen immediately when the device is tilted a certain amount.

ice cream sandwich..

Do you guys think ice cream sandwich can keep up with ios's smoothness? I used to hate apple and still don't like itmuch, but if ice cream sandwich won't be at least almost as smooth as ios, then i will definitely think about getting an ipad and selling my android tablet.. ios 5 has a lot of features that can keep up with current android, and it gives a really good experience with buttery smooth transition animation, although a little less feature. I know we should wait till tmr to find out all the features of ics, but do you guys think it will be smooth with no lag, especially the jerkiness when scrolling?

If your tablet is exceedingly jerky you should try wiping it or getting a replacement.
Besides that, I have no doubt that there will be plenty of under the hood improvements along with the UI updates.

Thanar said:
If your tablet is exceedingly jerky you should try wiping it or getting a replacement.
Besides that, I have no doubt that there will be plenty of under the hood improvements along with the UI updates.
Click to expand...
Click to collapse
I was going to say... "what jerkiness?"

Cactus42 said:
I was going to say... "what jerkiness?"
Click to expand...
Click to collapse
If you've ever used a current ios device then you know exactly what he's talking about. my a500 overclocked at 1.5 on a fresh install, is nowhere near as smooth as an ios device. There are certain jitters when performing certain actions. And lag when typing is a huge issue, that I can't seem to fix regardly of rom choice keyboard choice or overclock settings.

I'd recommend waiting until tomorrow night. They might pull out something "amazing" like with froyo and increase speed across the board again.

What little I have been reading about it Google is really working on UI, including trying to speed up transitions and effects. Whether or not they succeed remains to be seen, so my advice is: don't throw out the baby with the bath-water. Wait until you get a chance to actually try it YOURSELF once it's out and ignore rumours.

Yea comparing to ios, my tablet (usually smooth) is very jittery. And one thing that I haven't been doing much but started doing a lot is using it in portrait mode, and I just can't stand the lag.. and i really hope there will be at least close amount of various animation that are present in ios..and I REALLY hope the scrolling lag will be gone, like in youtube app, or actually any other app, when scrolling while loading image or something, is laggy. After I've spent some time with ios in a retail store, I really can't stand the lag haha..
WereCatf said:
What little I have been reading about it Google is really working on UI, including trying to speed up transitions and effects. Whether or not they succeed remains to be seen, so my advice is: don't throw out the baby with the bath-water. Wait until you get a chance to actually try it YOURSELF once it's out and ignore rumours.
Click to expand...
Click to collapse
And yea, I hope they succeed. I will definitely try it out. I THINK windows phone 7 is pretty smooth and ios is of course smooth but was wondering, why the biggest software company cant make their os better. Than apple and microsoft. I mean that in the general transition effect in terms of smoothness, not the OS features.

sw6lee said:
And yea, I hope they succeed. I will definitely try it out. I THINK windows phone 7 is pretty smooth and ios is of course smooth but was wondering, why the biggest software company cant make their os better. Than apple and microsoft. I mean that in the general transition effect in terms of smoothness, not the OS features.
Click to expand...
Click to collapse
Well, atleast partially the reason is technical: Apple's iOS is all native code AFAIK and tuned for Apple's hardware. After all, Apple controls all the parts that go to their devices and only choose parts that they know will work on iOS. Google on the other hand has to provide an OS platform that is a lot more malleable and can run on a wide range of devices with wildly differing characteristics, so it creates some overhead. Plus Android isn't native code, so again that creates some execution overhead.
And well, remember that iOS builds on OSX, it's just streamlined and tuned for mobile devices whereas Android is a completely new OS and Google doesn't have much previous experience in OS development. Ie. Apple has a lot of headway compared to Google and it'll take some time for Google to catch up.

WereCatf said:
Well, atleast partially the reason is technical: Apple's iOS is all native code AFAIK and tuned for Apple's hardware. After all, Apple controls all the parts that go to their devices and only choose parts that they know will work on iOS. Google on the other hand has to provide an OS platform that is a lot more malleable and can run on a wide range of devices with wildly differing characteristics, so it creates some overhead. Plus Android isn't native code, so again that creates some execution overhead.
And well, remember that iOS builds on OSX, it's just streamlined and tuned for mobile devices whereas Android is a completely new OS and Google doesn't have much previous experience in OS development. Ie. Apple has a lot of headway compared to Google and it'll take some time for Google to catch up.
Click to expand...
Click to collapse
I truly love your informative posts... Thanks for being a part of this community.

Euclid's Brother said:
I truly love your informative posts... Thanks for being a part of this community.
Click to expand...
Click to collapse
Eh. I'm somewhat surprised to get such feedback, usually I just hear that I'm an arrogant bastard. But well, thanks. I just saw an opportunity for giving some real feedback in an effort to stop an oncoming flamewar.

WereCatf said:
Eh. I'm somewhat surprised to get such feedback, usually I just hear that I'm an arrogant bastard. But well, thanks. I just saw an opportunity for giving some real feedback in an effort to stop an oncoming flamewar.
Click to expand...
Click to collapse
arrogant bastard, a great beer!

Come on, don't give up on android, for sure ios have by far the most smooth scrolling, but android gave you the fun to improving it. I get alot of satisfaction by flashing roms, kernels, overclocking, overcharging or simply playing around with the theme and designing your own styling. It's open and free. ois is all about giving you something that's good at a ridiculously high price...

iOS is definitely more refined when it comes to animations, ascetics, and fine detail. All of which creates a more pleasing (to look at) and responsive UI.
My iOS devices do occasionally succumb to the same animation stutters and laggy keyboard as my Android ones. However, usually only after a jailbreak and installing homebrew.
My biggest complaint with Android tablets (and android in general) is App support. Tablet app selection is dismal on Android and compatibility with 2.3 apps even worse.

sw6lee said:
Do you guys think ice cream sandwich can keep up with ios's smoothness? I used to hate apple and still don't like itmuch, but if ice cream sandwich won't be at least almost as smooth as ios, then i will definitely think about getting an ipad and selling my android tablet.. ios 5 has a lot of features that can keep up with current android, and it gives a really good experience with buttery smooth transition animation, although a little less feature. I know we should wait till tmr to find out all the features of ics, but do you guys think it will be smooth with no lag, especially the jerkiness when scrolling?
Click to expand...
Click to collapse
iOS was built from the ground up to use very little memory and CPU cycles. Remember when you couldn't even multitask on there? Well now all that has changed but Apple is sticking to the principle.
Android on the other hand is built upon Linux. Google is doing the very best with the software and tools they have. If you imitate iOS and remove all your widgets and satisfy with just some icons on your home screens it's highly likely you'll mimic very closely the experience of iOS in terms of the OS being lag free. Of course this varies from person to person in what and how many apps they are running, etc. Any apps that run services will take some toll on the system; herein lies an example of a big difference between how Android vs. iOS works.
Widgets also use up a chunk of memory as well as CPU cycles at a time and are one of the priority reasons the software may lag, especially some of those flashy ones like CNN/News widgets, big ones like Music/Video widgets or constantly moving ones like Weather/Time widgets.
We can only wait and see what ICS will bring. There's no guarantee that it will be any faster/smoother than Honeycomb is; for me Honeycomb is pretty damned smooth. Also Vanilla Android/Honeycomb doesn't consist of that many animations to start with unless you get 3rd party launchers...but scrolling for me and launching apps carries little to no lag with it.
Keep in mind also that momentum has built up and hardware has caught up with software demands. My G1 with 1.6 cannot begin to compare to my myTouch4G with 2.3 on it. If the trend continues we can more than likely safely assume that any sort of lag will disappear as more powerful processors are introduced.
Ultimately it's up to you to decide what's more important to you.
I'm not sure I could give up my widgets at this point just to get smoother animations as I have grown accustomed to and am now depending on them.
If you think you like iOS more for any reason, especially if you feel it now matches Android in terms of features, I'd definitely make the switch sooner than later. I'd hate to spend money on Android apps and then have to buy them all over again on iOS.

When would we reasonably except ICS to be available for the Acer Iconia?
Either for Rooted users or in a OTA upgrade?

I'd say about a month. People will probably have it booting (but that'll be about it) day of the source being released though.

Another bloke confirmed that Acer is planning on supporting the A500 with ICS.

So, today is the day. I'm EST, so 10pm for me.
Rather than start a new thread, I'm just throwing this in here incase anyone wants to chat about it later.
youtube.com/android
Of course it's a Samsung event but it should still provide some tasty insights.
//pun off

gammaRascal said:
So, today is the day. I'm EST, so 10pm for me.
Rather than start a new thread, I'm just throwing this in here incase anyone wants to chat about it later.
youtube.com/android
Of course it's a Samsung event but it should still provide some tasty insights.
//pun off
Click to expand...
Click to collapse
8:30 for central time

azoller1 said:
8:30 for central time
Click to expand...
Click to collapse
Lolwut...
Beyond that, i've never understood why the quality of an os is judged on its fancy animations. Truth be told, when given the option, i turn animations off to the highest degree possible.

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

This is a must-read.
https://plus.google.com/105051985738280261832/posts/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

Good find man, lot of useful info.
From Degobah

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.
Dianne Hackborn said:
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-content/uploads/2010/12/2-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.
Click to expand...
Click to collapse

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

Award Tour said:
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
Click to expand...
Click to collapse
1) Faster app-switching IS improved performance.
2) Maybe you skimmed past this part?
"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."
Click to expand...
Click to collapse

matt2053 said:
1) Faster app-switching IS improved performance.
2) Maybe you skimmed past this part?
Click to expand...
Click to collapse
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

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.

Award Tour said:
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
Click to expand...
Click to collapse
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

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.
Click to expand...
Click to collapse
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.

matt2053 said:
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
Click to expand...
Click to collapse
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

Award Tour said:
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
Click to expand...
Click to collapse
I didn't get from her post that hardware rendering within app windows would be disabled. Just that certain parts of the UI will be drawn with software executed by the CPU.
Sent from my Galaxy Nexus using XDA App

Good read! Thanks for posting

Not bad
Thx

matt2053 said:
This is a must-read.
https://plus.google.com/105051985738280261832/posts/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
Click to expand...
Click to collapse
Thanks for the info
Sent from my Nexus S 4G using xda premium

My comments, since I do some graphics work professionally:
Either I'm reading this wrong or Android has an extremely stupid rendering design. I do professional embedded GL graphics (and some Qt) so I'm not up to date with the Android framework yet:
* Why isn't drawing a client-server model where all draw commands are funneled to a unified multi-threaded draw server? That way, each app doesn't need a 8MB chunk of driver memory (which is stupid in itself already especially on embedded, Windows Mobile, Qt on Windows Mobile, etc). Only full-screen apps should have direct rendering to the framebuffer. Android is already suffering from draw consistency, resource contention by allowing each app to direct render. C-S would separate touch event contention from drawing contention that each Android app suffers from and why iOS has smoother UI.
* Why isn't Android using a multi-process scene-graph (each app is a item, and then each item has multiple sub-graphs per app) so Android can not only retain what needs to be drawn per global animation updates, but can instantly and easily cull unnecessary updates per app. Putting each app into an overlay isn't the best way to go without this culling.
* Why isn't Android using "dirty-regions" as another way to cull necessary updates (I assume this is what tiles are)? It should be since its a standard technique that dates back to QuickDraw and QuickDraw II, besides MS's windows API.
* With the pixel-overdraw bandwidth issue, Android can easily first cull through the scene-graph, then the per-app dirty-regions (or stencil buffer*), and then use the hardware-accelerated *depthbuffer to eliminate more overdraw, and draw front-to-back. This is just simplified because there's more modern GL tricks for culling. So, Android shouldn't have to touch each displayed pixel more than once.
* Is Android using pixelshaders at all to accelerate standard widgets such as buttons, etc? There's no reason to have large simplified buttons that can't be replicated by instanced models with pixel-shaders in a scene-graph.
Maybe Android should switch to the Unreal Engine for drawing instead, or some other modern game engine. These are all solved issues. Android has hardware that's generations more performant than the old game systems, but a software engine that's generations behind.

.
lol in other words no iOS smoothness for us fail I hope ICS hooks up my nexus s tho

NuShrike said:
Maybe Android should switch to the Unreal Engine for drawing instead, or some other modern game engine. These are all solved issues. Android has hardware that's generations more performant than the old game systems, but a software engine that's generations behind.
Click to expand...
Click to collapse
Aye, I agree with you there!!!!!

NuShrike said:
My comments, since I do some graphics work professionally:
Either I'm reading this wrong or Android has an extremely stupid rendering design. I do professional embedded GL graphics (and some Qt) so I'm not up to date with the Android framework yet:
* Why isn't drawing a client-server model where all draw commands are funneled to a unified multi-threaded draw server? That way, each app doesn't need a 8MB chunk of driver memory (which is stupid in itself already especially on embedded, Windows Mobile, Qt on Windows Mobile, etc). Only full-screen apps should have direct rendering to the framebuffer. Android is already suffering from draw consistency, resource contention by allowing each app to direct render. C-S would separate touch event contention from drawing contention that each Android app suffers from and why iOS has smoother UI.
* Why isn't Android using a multi-process scene-graph (each app is a item, and then each item has multiple sub-graphs per app) so Android can not only retain what needs to be drawn per global animation updates, but can instantly and easily cull unnecessary updates per app. Putting each app into an overlay isn't the best way to go without this culling.
* Why isn't Android using "dirty-regions" as another way to cull necessary updates (I assume this is what tiles are)? It should be since its a standard technique that dates back to QuickDraw and QuickDraw II, besides MS's windows API.
* With the pixel-overdraw bandwidth issue, Android can easily first cull through the scene-graph, then the per-app dirty-regions (or stencil buffer*), and then use the hardware-accelerated *depthbuffer to eliminate more overdraw, and draw front-to-back. This is just simplified because there's more modern GL tricks for culling. So, Android shouldn't have to touch each displayed pixel more than once.
* Is Android using pixelshaders at all to accelerate standard widgets such as buttons, etc? There's no reason to have large simplified buttons that can't be replicated by instanced models with pixel-shaders in a scene-graph.
Maybe Android should switch to the Unreal Engine for drawing instead, or some other modern game engine. These are all solved issues. Android has hardware that's generations more performant than the old game systems, but a software engine that's generations behind.
Click to expand...
Click to collapse
In case anyone wonders, this was Romain Guy's reply to the questions above:
"We use dirty regions and overdraw would not be eliminated through the use of a depth buffer since pretty much everything drawn by apps requires blending. We user fragment shaders and instanced models already. Apps don't have access to the framebuffer, they draw inside what we call a "surface" which is basically an OpenGL texture used by a separate process (the window compositor.) Android 3.0 already moves towards a full scene graph approach by keeping a tree of display lists (one per View) inside each window."
Click to expand...
Click to collapse

barmanham said:
lol in other words no iOS smoothness for us fail I hope ICS hooks up my nexus s tho
Click to expand...
Click to collapse
I don't even consider iOS that smooth. Multitasking and app switching in that OS is a big pain. My IP4 and iPod touch 4th slows down a lot when multitasking. To a point that it freezes for seconds.
Sent from my Nexus S using XDA App

I posted with my girls pre 2 and the multitasking in that is perfect
Sent from Oxygen 2.3.2 powered Nexus S 4G

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

A former intern for Google's Android team has provided explanations for why Android experiences more touch interface lag than competing mobile operating systems from Apple, Microsoft and Research in Motion.
Undergraduate software engineering student Andrew Munn posted his observations on Google+, as noted by Cult of Mac. He did disclaim, however, that he will be starting an internship with Microsoft's Windows Phone team in January, adding that any opinions from the report were his alone.
According to Munn, Android has a difficult time dealing with the touch interface because it handles rendering "on the main thread with normal priority," as opposed to iOS, which treats UI rendering with real-time priority. He cites examples of website loading and the Movies app on Android where the operating system will continue to load while registering touch input.
Munn identified several other factors that contribute to UI lag on Android. For instance, the photo gallery app in either Android 3.0 Honeycomb or 4.0 Ice Cream Sandwich is capped at 30 frames per second in order to prevent a noticeable "hiccup" at 60 FPS.
"Capping the frame rate at 30 fixes the hiccup problem at the expense of buttery smooth animations at all times," he said.
The author also pointed to hardware issues for Android. According to him, Nvidia's Tegra 2 chip limits Android because of its low memory bandwidth and lack of NEON instruction set support. Tablets based on Honeycomb would be "better off with a different GPU," such as the Samsung Hummingbird or Apple A4.
Munn noted that Android "has a ways to go" before achieving more efficient UI compositing, especially when compared against Apple's iOS.
"On iOS, each UI view is rendered separately and stored in memory, so many animations only require the GPU to recomposite UI views," he said. "GPUs are extremely good at this. Unfortunately, on Android, the UI hierarchy is flattened before rendering, so animations require every animating section of the screen to be redrawn."
Another reason for the lag is the limitations of Android's Dalvik virtual machine, which is "not as mature" as a desktop-class Java VM, Munn said. However, the issue with Dalvik will be offset by hardware acceleration from Ice Cream Sandwich on and improvements to Dalvik.
But, in spite of the improvements, Munn believes the Android user interface "will never be completely smooth because of the design constraints" that limit UI rendering to the main thread of an app with normal priority.
"Even with a Galaxy Nexus, or the quad-core EeePad Transformer Prime, there is no way to guarantee a smooth frame rate if these two design constraints remain true," he said. "It’s telling that it takes the power of a Galaxy Nexus to approach the smoothness of a three year old iPhone."
According to Munn, the reason behind the design change is that the original Android prototype didn't have a touchscreen, as it was meant to be a BlackBerry competitor. As such, Android's architecture is meant to support a keyboard and trackball. Munn further claimed that after the original iPhone arrived in 2007, Google rushed to complete Android, but "it was too late to rewrite the UI framework."
He cited Windows Mobile 6.5, BlackBerry OS and Symbian as examples of other older operating systems that suffered similar problems with touch performance. Microsoft, RIM and Nokia have all abandoned those OSes in order to start from scratch. "Android is the only mobile OS left that existed pre-iPhone," the report noted.
Android Software Engineer Romain Guy admitted as much when he said that choices made years ago had contributed to work the team has to do now.
"Having the UI thread handle animations is the biggest problem," he said. "We are working on other solutions to try to improve this (schedule drawing on vsync instead of block on vsync after drawing, possible use a separate rendering thread, etc.) An easy solution would of course to create a new UI toolkit but there are many downsides to this also.”
According to the report, those downsides include the fact that apps would have to be rewritten to support the new framework, Android would need legacy support for old apps and work on other Android features would be held up while the new framework was being built.
"However, I believe the rewrite must happen, despite the downsides. As an aspiring product manager, I find Android’s lagginess absolutely unacceptable. It should be priority #1 for the Android team," Munn said.
UI Lag has long been an area for which reviewers have criticized Android. One recent usability study by Jakob Nielsen on Amazon's Android-based Kindle Fire found erratic scrolling and "huge lag in response after pressing command-buttons." Nielsen suspected that "sloppy programming" was causing the issue.
The New York Times' David Pogue also took issue with the Kindle Fire. "Animations are sluggish and jerky -- even the page turns that you'd think would be the pride of the Kindle team," he said in his review. "Taps sometimes don't register. There are no progress or 'wait' indicators, so you frequently don't know if the machine has even registered your touch commands. The momentum of the animations hasn't been calculated right, so the whole thing feels ornery."
Munn himself viewed the issue as damaging to Android's image. He also saw it as a violation of Google's guiding principles, which have generally led to faster, optimized products. Finally, he mentioned that UI lag breaks the direct 1-to-1 relationship that touch screens offer.
"The device no longer feels natural. It loses the magic. The user is pulled out of their interaction and must implicitly acknowledge they are using an imperfect computer simulation. I often get “lost” in an iPad, but I cringe when a Xoom stutters between home screens," he said.
To conclude, the report ended on a more upbeat note, with Munn voicing his belief that the Android rendering framework is in the hands of a capable team. "I know they will have it eventually," he said.
___________________________________________________________________
I`m sorry o hear this .. so is there any chances that google make android on same structure as ios?
I know IOS is for only Apple devices, and because of that is feeling so smoth .. but how windows (computer windows) can be smoth for all computer configurations? and Android can`t, even quad core can`t stable android ....

This article makes me think. Let`s hope that there will be future improvement on how Google will write it`s UI code. I mean, it`s sad to have an SGS2 or an quad-core powered phone/tablet and a OS to hold back it`s power.

And more or less in reply to this came a post by Dianne Hackborn, who is part of the Android development team, explaining why most of this was either irrelevant or wrong.
https://plus.google.com/105051985738280261832/posts/XAZ4CeVP6DC
Still, plenty of questions of course.

I heard that android was made for phones with buttons and because of this we have all problems ...

No way this is true.
Nope, the system is power smooth and no lag whatsoever. Nada.
The truth is IQ restricted to a few in Android. Be happy with what you got. All the user posted issues are IDIOT related, as a senior member reminded me.
/sarcasm off
Dalvik VM limitations were known and were a set back from the beginning (just like fat32). Nevertheless, they ''fixed it'' somehow, this is why Oracle is giving hard time to Google.
I can't say WP7/BBoS is smoother/better when compared to SGS2 GB...but both OS's are smoother when compared to appropriate hardware.

Student i see well that's not somebody that knows what they are talking about is it .
jje

This is false because thread priority can be assigned by the OS or even the software (in certain cases). The reason why the web browser in the iPhone is more responsive than in Android is as follows.
On the iPhone, the web browser is rendered with a tiling method, What this means is that the only things drawn in high quality are the "tile" that you see (everything on screen) as well as the immediately touching tiles. Ever notice that when you pan/scroll on iOS, it seems to only leap one page, similar to Page Down on your PC? This gives the browser time to dump tiles that are no longer adjacent while rendering the newly adjacent tiles in higher quality.
On Android, the entire page is rendered in the same quality. This is more work, so scrolling/panning/zooming fluidity suffers. This allows for a consistent but not as smooth approach. It also means that you can flick-scroll indefinitely.
On the SGS2, Samsung tried to implement the tiling approach but left in the Android scrolling limitations. This means that you can sometimes scroll faster than the page can keep up, causing a checkerboard affect (this is what Apple is hiding with their method).
On the ICS browser, Google also adopted the tiling method (finally), and managed to disguise the checkerboard affect by covering it with the webpage's default background color. The "checkerboard" is still there, but you never see or notice it. Anyway, I did a writeup with videos to illustrate this. Unfortunately, most idiots are taking the videos as fanboy fodder. They seem to think that the point was to show off how much better phone X is than phone Y, rather than to show the differences in approaches. The RAZR/Rezound will have these enhancements with their 4.x update.
http://www.anythingbutipod.com/forum/showthread.php?t=67100

Yep, pretty much accurate info here but this is only regarding browser smoothness. Responsiveness is another issue android seems to have. When you scroll in iOS the contents are almost always directly below your finger, not "lagging" behind your swipes trying to catch up as you normally see in Android. I'm no expert so I have no idea what the cause of this is.
jaykresge said:
This is false because thread priority can be
assigned by the OS or even the software (in certain cases). The reason why the web browser in the iPhone is more responsive than in Android is as follows.
On the iPhone, the web browser is rendered with a tiling method, What this means is that the only things drawn in high quality are the "tile" that you see (everything on screen) as well as the immediately touching tiles. Ever notice that when you pan/scroll on iOS, it seems to only leap one page, similar to Page Down on your PC? This gives the browser time to dump tiles that are no longer adjacent while rendering the newly adjacent tiles in higher quality.
On Android, the entire page is rendered in the same quality. This is more work, so scrolling/panning/zooming fluidity suffers. This allows for a consistent but not as smooth approach. It also means that you can flick-scroll indefinitely.
On the SGS2, Samsung tried to implement the tiling approach but left in the Android scrolling limitations. This means that you can sometimes scroll faster than the page can keep up, causing a checkerboard affect (this is what Apple is hiding with their method).
On the ICS browser, Google also adopted the tiling method (finally), and managed to disguise the checkerboard affect by covering it with the webpage's default background color. The "checkerboard" is still there, but you never see or notice it. Anyway, I did a writeup with videos to illustrate this. Unfortunately, most idiots are taking the videos as fanboy fodder. They seem to think that the point was to show off how much better phone X is than phone Y, rather than to show the differences in approaches. The RAZR/Rezound will have these enhancements with their 4.x update.
http://www.anythingbutipod.com/forum/showthread.php?t=67100
Click to expand...
Click to collapse

dinan said:
Yep, pretty much accurate info here but this is only regarding browser smoothness. Responsiveness is another issue android seems to have. When you scroll in iOS the contents are almost always directly below your finger, not "lagging" behind your swipes trying to catch up as you normally see in Android. I'm no expert so I have no idea what the cause of this is.
Click to expand...
Click to collapse
Depends on the device. This was absolutely true of my HTC Incredible on Android 2.1. With 2.2/2.3 and bloatware removed, the UI outside of the browser is more responsive than my wife's old iPhone 4, but a hair behind her new 4s (The 4 slowed down with iOS 5 due to the new notification shade). This goes back to a previous post I made in another thread where the iPhone's entire UI is GPU accelerated due to not having high requirements. Android's UI is more complex which causes OEMs to decide which elements are accelerated and which are not. In most newer phones the notification shade is always accelerated, the wallpaper is not, but the homescreens are to varying degrees. There is a fill-rate budget and the OEM has to decide what is accelerated and what isn't within this budget.
A prime example is the Nexus S vs. the Galaxy Nexus. While both use the SGX540 GPU, the Galaxy Nexus version is clocked higher and has MUCH higher performance. As such, the entire Galaxy Nexus UI is accelerated. However, for the Nexus S ICS build, only certain parts of the UI are accelerated. Google has gone on record as saying that this is due to hardware limitations.
I'd be willing to bet that this is why the Nexus One isn't getting ICS. The Adreno 200 GPU was subpar even when it came out. With the new overlays in ICS, the UI in the N1 would become laggier rather than smoother, as with previous releases. Google may have felt that the user experience of GB on the N1 is superior to that of ICS due to the new features. Even budget phones today using scaled down Snapdragon S2s or the older OMAP4 have a better GPU than what the N1 had.

sounds like a disgruntled employee speaking half truths.

Guess this guy never tried an sgs2. No lag whatsoever!
Sent from my GT-I9100 using XDA App

Pretty much spot on. You cnt disagree that ios is muuuuuch smoother than android and that it does lag at times. Student nailed it in my opinion. Well written. Ive always said it has a long way to go and quad core wont b much differnt to dual core phones. When i used a iphone 4s for a while.... it blew me away how slick it was. Future versions will hopefully only get better. But iphone cnt match android open source fun lol. .
Sent from my GT-I9100 using xda premium

Fizzerr said:
Guess this guy never tried an sgs2. No lag whatsoever!
Sent from my GT-I9100 using XDA App
Click to expand...
Click to collapse
Since when u have your s2? Cuz on my s2.. I get lag.. and you know when? UI. When unlocking.. when i close an app it takes some time to get to UI...and so on. And I am on stock firmware.

Cristitamas said:
Since when u have your s2? Cuz on my s2.. I get lag.. and you know when? UI. When unlocking.. when i close an app it takes some time to get to UI...and so on. And I am on stock firmware.
Click to expand...
Click to collapse
No lag whatsoever on my GSII. And on my iPhone 4S there is also no lag. Both aee extremely fluid in my opinion. Galaxy Nexus, GSII, and the 4S are the fastest phones on the market right now.
Sent from my GT-I9100 using xda premium

Fizzerr said:
Guess this guy never tried an sgs2. No lag whatsoever!
Sent from my GT-I9100 using XDA App
Click to expand...
Click to collapse
In fact, when scroll in tapatalk lags, when im moving in desktop and receive a message of whats app or miyowa messenger lags too.

iNeri said:
In fact, when scroll in tapatalk lags, when im moving in desktop and receive a message of whats app or miyowa messenger lags too.
Click to expand...
Click to collapse
It lags...period lol
Sent from my GT-I9100 using xda premium

androidkid311 said:
It lags...period lol
Click to expand...
Click to collapse
Correct. So far any Android device lags. Any phone, any tablet, all of them. Sure, we are lucky to have one of the more lag-less devices but anybody who says the SGS2 doesn't lag at all either:
a) is ignorant
b) is very easy to please
c) is blinded by Android fanboyism
d) hasn't seen a true lag free device yet.
The SGS2 lags. Sometimes a little, sometimes like crazy, so be it. Don't claim otherwise.

Yes, my old xperia x10 lagged all the time. But my custom-ROM-running sgs2 doesn't lag. Yes, I've had an iPhone 4 for 8 months so I can compare them.
IMHO, lag is mostly placebo and expecting too much these days. Ugly code can cause the UI to stutter on every platform, including iOS.
# Galaxy S II w/ tapatalk

Pfeffernuss said:
The SGS2 lags. Sometimes a little, sometimes like crazy, so be it. Don't claim otherwise.
Click to expand...
Click to collapse
LOL. You must have a heap of bloatware on that thing. Either that or you've flashed a dodgy ROM. I get no lag at all. I think you are getting lag confused with app loading time. If you fire up Asphalt 6 and it takes 10 seconds to load that's not lag. Have a play with a Galaxy S on one of the earlier ROM's. Then you will see lag.
Sent from my GT-I9100 using XDA App

Fizzerr said:
LOL. You must have a heap of bloatware on that thing.
Click to expand...
Click to collapse
No bloatware whatsoever.
Either that or you've flashed a dodgy ROM.
Click to expand...
Click to collapse
Tried many many Roms, many many kernels, many many Launchers, etc. All the same thing. The phone will once in a while lag and/or show micro-stutters.
I get no lag at all.
Click to expand...
Click to collapse
None at all, really. A statement like that makes all the other things you say worthless. Every Android device will once in a while lag and/or expose micro-stutters.
I think you are getting lag confused with app loading time. If you fire up Asphalt 6 and it takes 10 seconds to load that's not lag.
Click to expand...
Click to collapse
I know what lag is, thank you.
It's exactly the same as when people say "my screen is perfect. I have no yellow/darker left side on my panel". When you check it yourself of course the panel isn't even. Usual reply? "Well, I don't see it so it doesn't bother me". That's not the point, it's there. The fact that the phone is 100% smooth for you is nice, only it is not.
Your SGS2 also will have occasional lag/micro stutters. In all apps/all the time? No. In most apps/usually? No. In some apps/occasionally? Yes.
Is it still an amazing phone? For sure. Probably the best/smoothest Android so far? Guess so. Does it sometimes lag and/or stutter? Absolutely.