Related
I'm almost positive there was a previous thread about this issue, but I can't seem to find it. In any case, I've noticed that the touch sensor lags behind my finger considerably. I recorded a video with two tests consisting of a. A quick demo with the multitouch visualizer app, and b. A half-assed game of table tennis.
http://www.youtube.com/watch?v=5j7cYb7EtUM
This issue has also been noted by Android Central in one of their tests of the Evo's multi touch capabilities.
http://www.youtube.com/watch?v=ieuB0VvkmwA
As you can see, the video clearly demonstrates a problem with either the hardware or software. The HTC Incredible uses the exact same touch sensor, yet exhibits none of these issues. As a result, I'm kind of doubtful it's an issue with the hardware. I'm sorry, but for such a high-end smartphone, I would expect better from HTC. Here's to hoping they address this problem in a future software update.
yeah.. im kinda disappointed in EVO..
personally, it not that big of a deal. So it's another obstacle while playing air hockey, just something to make the game more exighting. If you really are disappointed in a beast of a phone as this for having some touch sensor lag.... go dig a hole and bury yourself in it.
Rennat said:
personally, it not that big of a deal. So it's another obstacle while playing air hockey, just something to make the game more exighting. If you really are disappointed in a beast of a phone as this for having some touch sensor lag.... go dig a hole and bury yourself in it.
Click to expand...
Click to collapse
That really is not a good excuse for this issue. I don't want air hockey to be more exciting or challenging. I want the paddle to track my finger as accurately as every other high-end smartphone on the market. I have every right to be disappointed, because this isn't 'some' touch sensor lag. In fact, it's quite severe. I paid good money for a good smartphone, and I, along with the rest of the Evo owners, deserve better than this. We shouldn't have to settle for 'not that big of a deal'.
The lag is not on pressing buttons I think, I think it's when you drag stuff.
I mean I tried on my Droid and it feels slow to respond on the emulators with touch controls, but the Evo is slow as well. Also when clicking stuff it feels instant.
jigglywiggly said:
The lag is not on pressing buttons I think, I think it's when you drag stuff.
I mean I tried on my Droid and it feels slow to respond on the emulators with touch controls, but the Evo is slow as well. Also when clicking stuff it feels instant.
Click to expand...
Click to collapse
Well no, there's no lag on pressing buttons. The touch sensor can easily handle a single tap, since it isn't necessarily tracking anything. When it comes to playing something like table tennis though, the problem becomes painfully obvious.
Mecha2142 said:
That really is not a good excuse for this issue. I don't want air hockey to be more exciting or challenging. I want the paddle to track my finger as accurately as every other high-end smartphone on the market. I have every right to be disappointed, because this isn't 'some' touch sensor lag. In fact, it's quite severe. I paid good money for a good smartphone, and I, along with the rest of the Evo owners, deserve better than this. We shouldn't have to settle for 'not that big of a deal'.
Click to expand...
Click to collapse
You're missing my point. I meant to say that is a little bug in the screen tracking going to influence your desission on whether you are cool with he phone or not? Ever phone will always have minor bugs that you just have to live with. Now tell me, can you name any of your last phone's 'little bugs'? I had a Palm Pre, and I loved it. I will say the build quality was crap and I had to return it 3 times but I still enjoyed the phone. The Evo by the looks of things doesn't have any problems with hardware but the memory card issue that got resolved within a few hours of release.
Rennat said:
I meant to say that is a little bug in the screen tracking going to influence your desission on whether you are cool with he phone or not? Ever phone will always have minor bugs that you just have to live with. Now tell me, can you name any of your last phone's 'little bugs'? I had a Palm Pre, and I loved it. I will say the build quality was crap and I had to return it 3 times but I still enjoyed the phone.
Click to expand...
Click to collapse
Yes, this little 'bug' is going to influence my decision because it shows utter negligence on behalf of HTC regarding their flagship device. A minor bug is the notification light going off every once in a while. A minor bug is not the main input method lagging behind by at least a second. This is a bug I'd rather not have to live with if HTC can fix it. What if all smartphones had this 'little bug'? I'm pretty sure nobody would just accept living with it.
When a G1 outperforms an Evo in terms of touch input tracking, there is a serious problem.
Agreed. I'd like to get this resolved. It isn't a deal breaker to me, but it is shocking that a device like this would have a significant issue with the touch sensor. I have a feeling that tracking can just be updated with a future software update, but if/when this occurs is anyone's guess.
This is definitely a software issue. From Chipworks:
Touch Screen controller
The Atmel device provides for up to 224 nodes (hence being called MXT224?) and a patented charge transfer technology that allows it to be used even in netbook screens (>10”). It features an SNR of 80:1, and an extremely fast refresh rate. All in all, the nearest competing off-the-shelf touch screen at the time of introduction has only half as many nodes, a screen refresh rate of only 83Hz (66% slower) and an SNR of only 25:1 (66% less). Another thing, it can recognize (first in the industry) not only touch but also stylus, fingernails and gloved hands. Because of the high SNR rate, the device consumes a smaller amount of power and a decreased response time (due to it not being required to make use of extra filtering circuitry).
Click to expand...
Click to collapse
zeuzinn said:
This is definitely a software issue. From Chipworks:
Click to expand...
Click to collapse
Right. Now that you mention it, this might have some correlation with the 30 frames per second cap on the Evo. I mean, most other phones run at 60fps, and they have no problem tracking touch input. What's possibly going on is that because the phone is limited to 30fps, the screen can't refresh nearly as fast as it has to in order to track the input...
Mecha2142 said:
Right. Now that you mention it, this might have some correlation with the 30 frames per second cap on the Evo. I mean, most other phones run at 60fps, and they have no problem tracking touch input. What's possibly going on is that because the phone is limited to 30fps, the screen can't refresh nearly as fast as it has to in order to track the input...
Click to expand...
Click to collapse
I was just thinking the same thing. Perhaps fixing the frame cap will resolve both issues.
Mecha2142 said:
Yes, this little 'bug' is going to influence my decision because it shows utter negligence on behalf of HTC regarding their flagship device. A minor bug is the notification light going off every once in a while. A minor bug is not the main input method lagging behind by at least a second. This is a bug I'd rather not have to live with if HTC can fix it. What if all smartphones had this 'little bug'? I'm pretty sure nobody would just accept living with it.
When a G1 outperforms an Evo in terms of touch input tracking, there is a serious problem.
Click to expand...
Click to collapse
As I said before.....
Rennat said:
You're missing my point. I meant to say that is a little bug in the screen tracking going to influence your desission on whether you are cool with he phone or not? Ever phone will always have minor bugs that you just have to live with. Now tell me, can you name any of your last phone's 'little bugs'? I had a Palm Pre, and I loved it. I will say the build quality was crap and I had to return it 3 times but I still enjoyed the phone. The Evo by the looks of things doesn't have any problems with hardware but the memory card issue that got resolved within a few hours of release.
Click to expand...
Click to collapse
and no I don't care if the screen lag is hardware issue or software. If your going to yell and grip about this then go away. We really don't need ranters link you in the forum. The xda forum is to help others and create new ways of doing things and having more features.
At this point, I really don't care what you think. As you can tell from the other posts in this thread, and in fact the entire Evo forum, people do care about things like touch input lag, frame limit caps, and bad wi-fi reception.
Have you seen the thread on the Evo's graphical cap? Most people there seem pretty pissed off about the issue and want something done. Should they go away because they're 'ranters'? No, they're right because the only way to get things fixed is to point the problems out in the first place.
Mecha2142 said:
Yes, this little 'bug' is going to influence my decision because it shows utter negligence on behalf of HTC regarding their flagship device. A minor bug is the notification light going off every once in a while. A minor bug is not the main input method lagging behind by at least a second. This is a bug I'd rather not have to live with if HTC can fix it. What if all smartphones had this 'little bug'? I'm pretty sure nobody would just accept living with it.
When a G1 outperforms an Evo in terms of touch input tracking, there is a serious problem.
Click to expand...
Click to collapse
This is not a bug. As of now, the android base will have a minor delay, especially when it comes to user interface because that is just the way java is. Which is why you will not notice it in dalvik prepped apps.
That being said I don't notice it at all after switching to the evo. I did notice it on my hero. There was always a solid delay between my finger and anything it does. On the evo I would say it is almost gone for me. But everyone always compares it to the iphone which is not java but I remember reading about the comparable delays between the two platforms and its there on the iphone <= 3gs but its just not as noticeable.
To each his own but I see way more advantages in waiting for Froyo/JIT on this platform, at least until apple opens up a bit, which will never happen.
EDIT: By the way, RUU the device because I can tell you right now of the two evo's I have played with neither had an input lag anywhere NEAR a second. If that is in fact true I believe the device or install has got something wrong with it. Or it could be a runaway app that has been installed.
flexgrip said:
This is not a bug. As of now, the android base will have a minor delay, especially when it comes to user interface because that is just the way java is. Which is why you will not notice it in dalvik prepped apps.
That being said I don't notice it at all after switching to the evo. I did notice it on my hero. There was always a solid delay between my finger and anything it does. On the evo I would say it is almost gone for me. But everyone always compares it to the iphone which is not java but I remember reading about the comparable delays between the two platforms and its there on the iphone <= 3gs but its just not as noticeable.
To each his own but I see way more advantages in waiting for Froyo/JIT on this platform, at least until apple opens up a bit, which will never happen.
EDIT: By the way, RUU the device because I can tell you right now of the two evo's I have played with neither had an input lag anywhere NEAR a second. If that is in fact true I believe the device or install has got something wrong with it. Or it could be a runaway app that has been installed.
Click to expand...
Click to collapse
Haha this guy doesn't know what he's talking about. Are you saying that my Motorola Droid, which DOESN'T have the input lag, is because it's not running java vm on Android? hahahaha Java VM has nothing to do with the lag on Evo's input.
Not really sure where I said that the moto droid is not based on java or anything of the sort. Pretty much ever developer knows that java ui performance is mostly crap.
For example eclipse and OOO. Perfect examples. They have purely unacceptable lag in their UI.
Nearly ALL user interfaces based on java have a laggy UI. As a developer I made a conscious choice to not use java based ui and go with gtk/clutter. I have played with several motorola droids and they all have a solid delay that in most circumstances does not exist on the iphone. It is a pretty common reason for folks to not use java to build their apps. Take a good look at the sandbox dalvik apps. Even under the android emulator they are much more responsive.
I DO NOT see the moto droid having less delay than my evo. I think you are mistaking frame rate for input lag. As icons are moving, they look "jittery" or skip around. That is a long shot from saying there is a 1 second delay between your finger and movement on the screen. I had an app crash the other day while downloading files to the SD card and the whole system slowed down and had this massive input delay. So all I was really saying was try and see if there is maybe something you have installed that has made this happen because everything seems pretty "instant" to me, coming from the hero. Obviously it could be that my opinion is relative to my hero. But I notice that the evo is a bit snappier than the incredible. And that is backed up by a few reviews.
flexgrip said:
Not really sure where I said that the moto droid is not based on java or anything of the sort. Pretty much ever developer knows that java ui performance is mostly crap.
For example eclipse and OOO. Perfect examples. They have purely unacceptable lag in their UI.
Nearly ALL user interfaces based on java have a laggy UI. As a developer I made a conscious choice to not use java based ui and go with gtk/clutter. I have played with several motorola droids and they all have a solid delay that in most circumstances does not exist on the iphone. It is a pretty common reason for folks to not use java to build their apps. Take a good look at the sandbox dalvik apps. Even under the android emulator they are much more responsive.
I DO NOT see the moto droid having less delay than my evo. I think you are mistaking frame rate for input lag. As icons are moving, they look "jittery" or skip around. That is a long shot from saying there is a 1 second delay between your finger and movement on the screen. I had an app crash the other day while downloading files to the SD card and the whole system slowed down and had this massive input delay. So all I was really saying was try and see if there is maybe something you have installed that has made this happen because everything seems pretty "instant" to me, coming from the hero. Obviously it could be that my opinion is relative to my hero. But I notice that the evo is a bit snappier than the incredible. And that is backed up by a few reviews.
Click to expand...
Click to collapse
Move your finger faster on the screen. Your finger will be going one direction while the interface is still going another direction. The delay is greater than the difference between 30 and 60FPS.
flexgrip said:
Not really sure where I said that the moto droid is not based on java or anything of the sort. Pretty much ever developer knows that java ui performance is mostly crap.
For example eclipse and OOO. Perfect examples. They have purely unacceptable lag in their UI.
Nearly ALL user interfaces based on java have a laggy UI. As a developer I made a conscious choice to not use java based ui and go with gtk/clutter. I have played with several motorola droids and they all have a solid delay that in most circumstances does not exist on the iphone. It is a pretty common reason for folks to not use java to build their apps. Take a good look at the sandbox dalvik apps. Even under the android emulator they are much more responsive.
I DO NOT see the moto droid having less delay than my evo. I think you are mistaking frame rate for input lag. As icons are moving, they look "jittery" or skip around. That is a long shot from saying there is a 1 second delay between your finger and movement on the screen. I had an app crash the other day while downloading files to the SD card and the whole system slowed down and had this massive input delay. So all I was really saying was try and see if there is maybe something you have installed that has made this happen because everything seems pretty "instant" to me, coming from the hero. Obviously it could be that my opinion is relative to my hero. But I notice that the evo is a bit snappier than the incredible. And that is backed up by a few reviews.
Click to expand...
Click to collapse
You drunk?
I have the Droid and the HTC EVO 4g.
Get the a touch input application
Scroll around with the Droid, instant.
Evo 4g super delay
This issue has nothing to do with Dalvik, or Java.
jigglywiggly said:
You drunk?
I have the Droid and the HTC EVO 4g.
Get the a touch input application
Scroll around with the Droid, instant.
Evo 4g super delay
This issue has nothing to do with Dalvik, or Java.
Click to expand...
Click to collapse
+1 its there and verified
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.
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
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.
We're currently working on a handwriting app using a stylus for Android platforms. We can draw plenty fast enough to keep up with the user using a simple SurfaceView implementation. The problem is the ubiquitous Android touch lag that has been so well documented. I have not seen much of any improvement from ICS to JB. What we're currently seeing is a good 100+mS of lag when following a touch swipe on Android and actually being able to grab the coordinates from the OS. Our code basically runs the same now(as far as lag) whether it's on a quad core Galaxy Note or a dual core Marvell processor running at 800MHz. At this point I am frustrated with the state of the speed of the touch plumbing on Android. Now, I will be fair and state that I've tried some of the drawing apps on the iOS platform and at least in the drawing department, iOS isn't that much better than Android. The lag on iOS is nearly equivalent to Android. But note this is for drawing on the screen and following the touch events. All else; scrolling, swiping, iOS crushes Android as far as responsiveness. I recognize these devices are running a high level OS and we shouldn't expect real time performance but I am still frustrated to say the least. A good handwriting app needs a responsive touch system otherwise the human brain starts to disconnect their hand motion from what they see on the screen.
I've looked at the Seeder app but to be frank haven't used it since it requires a rooted device.
Can anyone chime in on the current state of the lag problem on Android? Are there are any solutions out there where we can get our apps to closely follow the touch coordinates without 100+mS of lag? I am willing to have to code my own plumbing to get the touch coordinates with less lag if that's what it takes.
http://www.macrumors.com/2013/09/21/iphone-5-touch-screen-twice-as-fast-as-android-touch-screen/
You've probably sorted this by now, but... specifically where do you observe 100ms lag ? From touching the screen to some point in your code ?
Even basic events like a button click don't fire for over 150ms after the user touches it. It's the same even when dealing with touch events directly.
i have some answer - sort of
microsoft is aiming for 1ms response time (other cmpys they wont say anything)
i dont think they have implemented in windows phone yet , but still i think response are pretty good compared to overloaded android
balance is must for any operationg system .
KurianOfBorg said:
Even basic events like a button click don't fire for over 150ms after the user touches it. It's the same even when dealing with touch events directly.
Click to expand...
Click to collapse
I'm a bit surprised by that, hadn't really noticed it on our app (which is a keyboard...) - how are you doing the measurement ? Would be interesting to give it a try.