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
Related
One thing I have wondered is why Android is so much further behind in terms of the snappiness and speed of scrolling compared to the iPhone.
Yes, the jerkiness and much of the lag has been completely removed with updates to 2.2 and the newer high-speed processors. However, the difference is extremely apparent even with comparing my 2.2 cyanogen Nexus One to an iPod Touch 2G I happened to pick up today.
The iPod touch's scrolling actually follows your finger, if you rapidly scroll up and down (or left and right), the UI does not lag behind the position of your finger. But on my Nexus One (and even on my friend's Evo with the FPS update), scrolling rarely keeps up with your finger. I even was able to have the page oscillate to the wrong position of my finger by quickly scrolling back and forth.
To me, this is single-handedly one of the most important problems with the Android operating system. Speed is not just the processor, it's how the UI interacts with the user.
My question is - What can we do about it?
It's almost certainly a software issue, unless android phones are using sub-par touch screens, which seems hard to imagine. Is there any way to optimize the sending of touch information to apps?
Just figured I'd throw it out here, as I've yet to find any other posts with similar concerns.
It's because iOS is totally built to support the gpu AKA hardware acceleration. Android OS mainly runs on software, instead of full hardware acceleration. Which is why IOS is much more fluid. But Gingerbread 2.3 is said to have true hardware acceleration, and it's coming soon
Sent from my Vanilla Tazz using XDA App
My sentiments exactly. "Speed is not just the processor, it's how the UI interacts with the user."
Its a combination of poor touch sensor, having multitasking and not enough hardware acceleration.
The nexus/desire can barely multitouch so super smooth scrolling may be too much to ask.
Try scrolling in the new youtube app from google on one of the latest phones (sgs,g2,dhd) its super smooth. Everything will be like that come gingerbread
Sent from my GT-I9000 using XDA App
With an exception in the program list, my HTC Tattoo handles scrolling very well! I am running a Froyo ROM on it that is definitely whats making it fast, and I really look forward for gingerbreads new UI and that it doesn't require too much of the phone as froyo runs great on my tattoo.
It's definitely possible that it's the touchscreen. One thing I did notice however that must be almost certainly part of the software is that there's a "buffer range" when the finger first presses down that the finger must move out of before the scrolling action is started.
Presumably this is to keep from confusing wild presses with scrolls, but on the iPhone that buffer range is far smaller than on the Android platform.
Due to this buffer, the scrolling action only really starts a few hundred milliseconds after I actually touch the screen.
I may find a Verizon store and check out some of the newer phones, I'm curious if they'll work better, than my Nexus One.
Dunno but there are some app's where scroling is smooth whereas it isnt with others, so I dont thinks it's all up to the touchscreen of my desire, for example the launcher pro app drawer is extremely smooth compared to the htc one and so on
I checked out a Verizon store, and I still have to say that there's definitely something off about the smoothness. Anyone who disagrees hasn't tried an Android phone side-by-side to an iPhone.
It also doesn't seem to be something that GPU acceleration could fix:
Romain Guy said:
A one year old NexusOne (and other devices before) is perfectly capable of scrolling a list at close to 60fps (limited by the display’s refresh rate.)
Click to expand...
Click to collapse
So the problem is really either the screen refresh rate, or the slight hiccup when starting the scroll. Other than that, I really can't determine the differing factor, especially since I'm comparing Android to a iPod Touch 2g; nothing that would have significant processing power.
Kleptine said:
I checked out a Verizon store, and I still have to say that there's definitely something off about the smoothness. Anyone who disagrees hasn't tried an Android phone side-by-side to an iPhone.
It also doesn't seem to be something that GPU acceleration could fix:
So the problem is really either the screen refresh rate, or the slight hiccup when starting the scroll. Other than that, I really can't determine the differing factor, especially since I'm comparing Android to a iPod Touch 2g; nothing that would have significant processing power.
Click to expand...
Click to collapse
just use a different launcher. Launcher pro and zeam are incredibly smooth
bobdude5 said:
just use a different launcher. Launcher pro and zeam are incredibly smooth
Click to expand...
Click to collapse
I'm not even using the Launcher. Specifically I've been testing on Astro File Manager (which seems to be the smoothest android application with a long list to use) and the new Youtube app which supposedly has a few optimizations of some sort.
Doesn't the android OS lack gpu acceleration?? Thus Apple devices are smoother
Sent from my Incredible using XDA App
That's true, but look at the comments on this page from Romain Guy himself:
http://www.curious-creature.org/201...-and-tips-tricks/comment-page-1/#comment-4928
According to him, GPU acceleration isn't much of the problem.
PLEASE DO NOT START A FLAME WAR!
As you can tell from my sig, I have recently acquired a new HD2, flashed and ready with the Windows Phone 7 OS, in addition to my Samsung Vibrant. I will try my best to provide an accurate comparison of WP7 vs Android from an unbiased standpoint, as I show equal likes and dislikes with both OSes and phones. Keep in mind I have a class 6 sd card in the hd2 so it should be just as fast if not faster than the HD7.
Navigation Efficiency/ Smoothness: I must say at first glance, WP7 may seem like a true winner with its GPU accelerated animations and scrolling, both of which are butter smooth. The flips and backflips of screens and icons is nice, as is the rotation swirl, and adds that bit of polish lacking in Android. However, if you look past the animations, you may realize that the Vibrant (modded), does open apps just a bit faster than WP7. The key to WP7 is the eye candy, those animations decrease the delay you may otherwise see with Android phones lacking fancy animation, turn off the animations on both and the Android device will likely open the app first, whether it be browser, Gmail, calculator, calender, etc.
Apps: Android, no doubt. The WP7 app store is sorely lacking apart from a few high quality games and apps such as Netflix. Sure, streaming movies is fun, but what about everything else? Not to mention, the WP7 marketplace strangely lacks a search feature, or just that I didn't dig deep enough.
Browsing: This is really half and half. Smoothness wise, WP7 is a winner with the GPU acceleration, again glass smooth. Page rendering such as Engadget had similar times, with non flash pages the HD2 won easily, but with flash turned off on both, I must say the Vibrant won. Both were connected to wifi at my house, with the Vibrant being 2-3 seconds ahead without flash. At times I question the use of flash on a device lacking hardware acceleration, but then again those white spots on screens where a occasional youtube video shows up on the HD2 is equally if not more annoying than the choppy Android browser. In the end, if you enjoy smoothness and text reading, and perhaps a bit of speed due to the lack of flash, the GPU accelerated WP7 browser will do you well, but if you prefer functionality and watching videos, go with Android 2.2.
I cannot provide information on camera quality due to having an HD2 hacked WP7.
The music player on WP7 is about the same in functionality as the Touchwiz version.
I will gladly provide more information if you need. Remember to click thanks if I helped.
The Windows Search button is context sensitive.
Maybe you're having trouble finding it on the HD2 (keymappings different, etc. /shrugs/ ), but you bring up marketplace search (or search in any app) by simply hitting the search key.
Flash was a huge deal to me, until I see how badly it nerfed the Vibrant's browser performance. Any setting other than off makes the browser perform terribly. The WP7 IE browser runs laps around it. Cutting it off boosts it a bit, but that's terrible since it has Flash Lite before and we didn't have to deal with such terrible performance... I don't hear any of my iPhone-using friends complaining about the lack of Flash.
App are meh. The only thing that matters are complex apps and games. Most mobile apps (non-game) tend to be encapsulations of mobile websites. An Engadget app doesn't make any sense to install, IMO, since I can just go to Engadget.com and the site is optimized for mobile browsers... Same with CNET, etc.
Some apps just aren't worth bringing to WP7. Office apps aren't worth bringing over. NoteTaking apps aren't worth bringing over. SMS Replacement Apps aren't worth bringing over. Exchange Clients. WP7 has Find My Phone/Lock/Wipe functionality built into it, so stuff like LookOut isn't much use (don't care about the sirens, a phone thief/finder will almost always shut the phone off immediately).
I'd say no browser except maybe Skyfire is worth bringing over at this point, because the chances of them outperforming IE on WP7 is slim to none. As far as apps are concerned, WP7 is probably the most consistent (in Look and Feel) and complete OS released to date when it comes to having all this stuff integrated and from a single vendor. Andorid manufacturers usually license different components from dispirate software vendors to "complete" the experience.
Cameras are comparable. Vibrant takes better pictures during the day. HD7 better at night due to the dual flash. The Vibrant tends to get a better framerate on video, but when blown up on a larger screen it looks a bit grainy and washed out (sort of like a painting). The HD7 doesn't suffer that issue, but the framerates are a big lower. I'd say it's a bit of a wash, with a slight edge to the HD7 because the Vibrant simply cannot compete at all in terms of night time picture shooting... It just can't, even with night mode, etc.
As far as the Navigation and smoothness of the system... The animations have nothing to do with it. It's basically iOS performance with extra eye candy to look better. The only thing that lags a bit is scrolling through lists (Android does this as well, but I think the fact that lots of applications load internet data on the fly has something to do with it in some instances) and resuming from apps (which will see significant performance boosts in the March update, among other things).
The animations aren't hiding any lag. We're seriously comparing a phone that lags switching home screens to a phone that can animate pretty much every transition without as much of a hickup. Let's not go there...
The Music Player is not the same functionality wise. WP7 uses Zune. The Vibrant uses the TouchWiz Music/Video player. Zune has FM Radio, can Stream Music if you have Zune Pass, and interfaces with the Zune software on the computer.
Galaxy S has nothing like XBox Live, which is useful even if you don't have any XBL games on your phone because you can send and recieve messages, etc. There are some good games on XBL/Marketplace, though.
I had an hd7,
Wp7 is smoother and more eye candy and better core functions.
Android has apps and open source support.
Sent from my Galaxy S using Tapatalk
I appreciate an actual HD7 owner coming in to improve my points.
And as to the transition animations, it is very likely that those are completely controlled by the gpu while the cpu is controlling the app openings and lifecycles. I seriously doubt that WP7 opens apps instantaneously, instead separating the gpu and cpu tasks for smooth animation while the cpu opens the app.
The Touchwiz music player is similar to that of the IPhone, which is comparable to Zune. I meant comparable, but Zune is milestone above that of the stock android music interface.
Camera on the HD2 really is a meh. Flash pics get overblown due to the dual flash and the pics are a bit grainy even with the replacement ShCameraApp. Most probably software issues, but the HD7 uses the same or similar hardware camera.
The IE browser really is just smoother than the android browser. You won't mind the lack of flash until you come across an embedded youtube video on a page with a black spot.
After the initial surprise by the smoothness of WP7, the lists and tiles do get a little boring.
The thing that bothers me the most is the need for zune to do everything from load pics and videos, to albums and anything onto the phone. Not that zune is bad, but it just hinders an otherwise easy drag and drop.
The HD2 is a keeper for me due to the solid metal and rubber build and its ability to run 4 OSes, 3 natively or almost natively (android, winmo, wp7, and hopefully meego). Plus I got it free from the Executive Response Team, no contract extension either (don't ask, long story).
And N8ter, I was not directly comparing WP7 to the Vibrant since I came from a Nexus One, but gave it up due to several power button failures and screen burn ins.
Yes the hd2 is the dev device of the century, the hd7 is just a slick version of it with a kickstand.
I loved the wp7 everything about it I just couldn't deal with lack of good app support.
It just works, well. No roms or anything needed.
That being said android has more possibilities and capabilities and of course dev support
Sent from my Galaxy S using Tapatalk
Android is the new windows mobile in my eyes. It has better marketing but the same problems with wm are still present. Lack of manufactures support, drivers for custom roms, and mostly manufactors adding there crapware on top of a great os.
I personally needed a break from Android and specifically the vibrant. I was constantly trying to fix problems. I think Android needs to set some rules/guidelines for OEMs that have the resources to put out great product. Open source is great for the community but letting companies put out crap with googles Android written crossed it.
I too tried wp7 on my hd2 and was surprised at the user interface. Almost lag free device, and no need to change SMS, browser, music player etc. Everything works great out of the box besides YouTube. I've only installed slacker, flashlight, wp7 tapatalk, news/ RSS reader, Google voice and that's about it.
I will be back to Android later in the year but for now I just need something that works. With me bring a heavy user I was able to get thru a full day on a single charge.
I will miss my screen a little, my torrent app, and my remote desktop app. Out of all the apps in Android maybe 20 apps were useful to me besides pulling out the ruler vs my friends.
Zune computer software is great. Syncs extremely fast and haven't had a problem yet. No more fighting with my external sd.
Things that are important to me:
Browser
Music
Google voice
Text and email
Little facebook/twitter.
Battery life.
A couple snap shots occasionally
Wp7 does these with no problem.
Sent from my HD7 using Board Express
I don't think any Mobile OS or device should be dependent on third-party dev support to make the phone function as advertised. That is part of the issue with Android (not as a whole, but specific [even most] manufacturers). The initial Honeycomb tablets may be different, though, since the manufacturers aren't initially skinning the OS.
The Motorola ATRIX, with all its great hardware goodness, lagged it's way to a 9/10 (cause it has lots of accessories?!) on Engadget. Maybe when their brain catches up (apparently lagging as well) they will get around to giving it a believable rating...
These reviews have been unchanging for the past year, year and a half. No matter how much hardware you throw at Android: "phone lags a lot", "you should be able to get a day out of it with moderate usage (some phones piss the users off if they have to charge more than ever other day - smartphones mind you)" "bad UI yada yada" "skin this and that" "still running older version but update coming *soon*".
XPLANE9 said:
I appreciate an actual HD7 owner coming in to improve my points.
And as to the transition animations, it is very likely that those are completely controlled by the gpu while the cpu is controlling the app openings and lifecycles. I seriously doubt that WP7 opens apps instantaneously, instead separating the gpu and cpu tasks for smooth animation while the cpu opens the app.
Click to expand...
Click to collapse
Hardware accelleration means graphics processing is offloaded to the GPU. Apps open as fast as they do on any other mobile OS, and faster than others. Of course if you're running a mobile game with (relatively) large files to load when it starts up this will not happen instantly. The use of the term instantaneous wasn't really meant to be taken uber literally...
Android runs less efficiently on better hardware because the system taxes the CPU more, since the GPU is going unused as far as the general UI/widgets are concerned. This is why the devices are usually overspecced and/or have functionality ripped out of them.
One of the biggest failures of Samsung was releasing this phone with such great GPU hardware in it, but not putting hardware accelleration into their firmware. Perhaps if they had done that the system would have run a bit smoothly. Nothing could save it from RFS, however.
The Touchwiz music player is similar to that of the IPhone, which is comparable to Zune. I meant comparable, but Zune is milestone above that of the stock android music interface.
Click to expand...
Click to collapse
I'm talking beyond the user interface. I'm accounting for functionality as well The TouchWiz music player is not comparable to iPod Touch in the iPhone. DoubleTwist makes an app that looks like iTunes, but iTunes obviously blows it away when it comes to features and functionality, for example.
Camera on the HD2 really is a meh. Flash pics get overblown due to the dual flash and the pics are a bit grainy even with the replacement ShCameraApp. Most probably software issues, but the HD7 uses the same or similar hardware camera.
Click to expand...
Click to collapse
The HD2's camera is actually pretty bad. I'm sure the cameras are similar, they are both 5MP cameras with 720p. But, I'm also sure they aren't the same, because the picture qualities are IMO a bit too different for that to be the case (even across multiple OSes on the HD2). That being said, I've never done a teardown, so I don't know for sure.
If anyone wants a great camera on a phone, it would behoove them to get an N8. That phone can compete with some DSLRs when it comes to picture quality.
The IE browser really is just smoother than the android browser. You won't mind the lack of flash until you come across an embedded youtube video on a page with a black spot.
Click to expand...
Click to collapse
I went from Vibrant to HD7 and don't mind the lack of flash. Flash, IMO, was not ready for mobile devices when it was released for Android. It's too bloated and resource intensive. It has this same issue on the desktop, but fortunately those machines are powerful enough to just shrug it off in most cases. Flash 10.2 is supposed to bring hardware accelleration, but I'm not sure how much that will help Galaxy S devices...
It causes a lot of Pinch-Zoom and Pan lag, and scrolling on a page with a few flash artifacts on it can be a PITA on some websites.
I do know some sites that crash the Android browser 100% of the time, though...
In the case of moving from Android to WP7, the lack of Flash was actually a bonus for me. If the Vibrant had shipped without Flash (needed it from the market) and Flash Lite was also available in the market, I'd probably have just installed Flash Lite 5 minutes after installing the FroYo update and trying Flash. The irony, though, is that Flash Lite worked for most of the crap that I needed Flash for... I regret even asking for [full] Flash.
After the initial surprise by the smoothness of WP7, the lists and tiles do get a little boring.
Click to expand...
Click to collapse
9 of the tiles on my WP7 home screen are Live. I'll take Live Tiles and normal tiles over walls of icon and widgets with no unified Look and Feel cluttered across 3-7 Home screens. Don't really care about the list. IIRC Android has an option to make the App "Page" a list as well...
The thing that bothers me the most is the need for zune to do everything from load pics and videos, to albums and anything onto the phone. Not that zune is bad, but it just hinders an otherwise easy drag and drop.
Click to expand...
Click to collapse
A phone is not a USB thumb drive.
Yes, however managing media on a WP7 or iOS device is much better than on Android, where this sort of stuff is non-existent in the stock builds and requires you to duplicate tons of functionality on the device, set defaults, etc.
There is DoubleTwist, whose Desktop App runs like a 1200lb Gorilla from my experiences (at least on Windows - I thought it was my computer, but I have 5 computers; fortunately), requires a redundant media player to be installed, and sells WiFi media synching (free in Zune).
WinAmp has media synching, but again requires a redundant media player.
WiFi Synching, Automatic Transcoding to the best possible format, etc. This is all done transparently. Once Microsoft Adds Skydrive support and that other stuff in Mango, I don't forsee many complaints about WP7.
But even now, it's a very polished experience. I even prefer the notifications on WP7 to Android, and I don't have to worry about numbers getting burnt into the top of my screen anymore.
The HD2 is a keeper for me due to the solid metal and rubber build and its ability to run 4 OSes, 3 natively or almost natively (android, winmo, wp7, and hopefully meego). Plus I got it free from the Executive Response Team, no contract extension either (don't ask, long story).
Click to expand...
Click to collapse
Yes, it's a great device that ran well even on WM. Marred by bad QA on the part of HTC. I never saw a reason to run another or a non-stock OS on my HD2s, personally.
And N8ter, I was not directly comparing WP7 to the Vibrant since I came from a Nexus One, but gave it up due to several power button failures and screen burn ins.
Click to expand...
Click to collapse
Meh, this is the Vibrant forum
All that said, I have all three phones and can choose to use whichever one I please whenever I want to. The Vibrant and the HD7 both have active SIM Cards in them with Data plans, so I can care less what anyone else choose, likes, dislikes, or doesn't choose. I don't have to choose anything, I just have to "prefer at that specific moment." XD
Kinda funny comparing a HD7 to a vibrant. Consider the Vibrant is now 9 months on the market and older tech than the HD7 2 months on the market.
So, The only things I have seen that i would like on the Android platform that the HD7 has over Vibrant
1. A better voice command
2. Flash on the camera
3. More user friendly custom contact menu (add custom ringtones and pics)
4. The Browser revised to integrate flash better.
5. Improve on the sound by adding a onboard equalizer.
That would make the phone alot more ZAPPY..... The S2 maybe ?
The HD7 is using HD2/Nexus One-level hardware. So the hardware is really like 6 months older than what's in the Vibrant. I have no clue how you can say the Vibrant has older tech than the HD7...
The S2 will be snappier than the Vibrant, but most likely because in typical Android OEM fashion, they will just throw hardware at it.
If the ATRIX 4G is any indicator, I don't expect this hardware to make too much of an impact. I think as time goes on Android's performance issues will start to work against it.
It's getting harder and harder to find a performant device and people make fun of Android because it is universally known as a laggy smartphone OS (check out BB or iOS forums, among others, and see).
all i want to know when moto atrix is getting ics.i also have sgs captivate and it is running on ics port and woking very well.so i also want to have ics on this phone also.pls do it quickly
sx4 said:
all i want to know when moto atrix is getting ics.i also have sgs captivate and it is running on ics port and woking very well.so i also want to have ics on this phone also.pls do it quickly
Click to expand...
Click to collapse
Seriously, SEARCH!! there's already too many threads about this. And writing another thread isn't gunna help it get here faster. We need another tegra device to get it first. You'd know this if you SEARCHED!!!!
Sent from my MB860 using XDA App
sx4 said:
all i want to know when moto atrix is getting ics.i also have sgs captivate and it is running on ics port and woking very well.so i also want to have ics on this phone also.pls do it quickly
Click to expand...
Click to collapse
This sense of entitlement is why devs are leaving XDA.
There is currently no ICS port. The group working on CM7 will be doing a version for CM9 but as with any version of CM, no etas. Next time use search. If you want ICS badly, you already have it on your captivate.
sx4 said:
all i want to know when moto atrix is getting ics.i also have sgs captivate and it is running on ics port and woking very well.so i also want to have ics on this phone also.pls do it quickly
Click to expand...
Click to collapse
If you want it so bad, port it hisself instead of giving orders in a somewhat polite way.
Sent from my MB860 using XDA App
sx4 said:
all i want to know when moto atrix is getting ics.i also have sgs captivate and it is running on ics port and woking very well.so i also want to have ics on this phone also.pls do it quickly
Click to expand...
Click to collapse
Pls do it quickly? Every dev in here is probably cursing your phone and hoping it breaks right before ics leaks. Might want to take your a la carts attitude to the windows phone forums.
Sent from my Galaxy Nexus using xda premium
[opinion]you will never see an official port for ICS from the Atrix, Atrix 2, or any device using the webtop.[/opinion]
In addition, the Atrix 4G has the FP scanner. These two features are going to kill any official support from Motorola. Why?
They are LAZY! The webtop was cobbled together in the first place. This is why the 'the optimus 2x is getting ICS' argument doesn't work in the case of the Atrix. Sure this will leave a bad taste in consumers' mouths, for maybe two seconds until they come out with something new and shiny. Seems people are willing to shell out hundreds of dollars for hardware that isn't even an upgrade, so why bother putting effort into updating software when it isn't profitable?
Its also worth noting that there are some parts of the world where GB isn't even an official release yet! Once they roll out GB in all regions, they will bury support for this phone six feet under, despite the customer objections.
Besides, our clandestine group of developers for the Atrix have pushed out better software than the official Moto devs ever could. You'll see a CM9 port before you even hear an utterance from Motorola to support the Atrix.
SirFork said:
you will never see an official port for ICS from the Atrix, Atrix 2, or any device using the webtop.
Click to expand...
Click to collapse
Source please!
CaelanT said:
Source please!
Click to expand...
Click to collapse
Aside from Motorola's track record, I have none. Hence, the several paragraphs explaining my reasoning. The lack of correspondence from Motorola (all I have gotten from them are canned almost political-sounding statements) and the present state of affairs for Atrix support in addition to the points I made previously are why I am extremely skeptical of ICS ever coming to the Atrix officially.
Of course I hope that I will eat my own words some day, like an ice cream sandwich
Edited my previous post to reflect as an opinion article not as fact.
SirFork said:
Aside from Motorola's track record, I have none. Hence, the several paragraphs explaining my reasoning. The lack of correspondence from Motorola (all I have gotten from them are canned almost political-sounding statements) and the present state of affairs for Atrix support in addition to the points I made previously are why I am extremely skeptical of ICS ever coming to the Atrix officially.
Of course I hope that I will eat my own words some day, like an ice cream sandwich
Edited my previous post to reflect as an opinion article not as fact.
Click to expand...
Click to collapse
Including the fact that since July, Motorola has released or is about to release the Droid 3, Bionic, RAZR, Droid 4, RAZRMAX, Photon 4G, Triumph, and Atrix 2. Throw on the Cliq 2, Atrix, and Droid X2 from earlier in the year.
im running ics on my atrix right now CM9, enginerring build, lots of things broken, def not for public and will not be made available for public for a while. so DO NOT ASK FOR IT. btw all credit to turl and atrix-dev-team. my point is, never say never because its already a fact.
samcripp said:
im running ics on my atrix right now CM9, enginerring build, lots of things broken, def not for public and will not be made available for public for a while. so DO NOT ASK FOR IT. btw all credit to turl and atrix-dev-team. my point is, never say never because its already a fact.
Click to expand...
Click to collapse
Great news! I'm sure none of us will be stupid enough to ask for ETA's!
I'm assuming no HW Acceleration and the good stuff. Have you heard about Nvidia's plans to release ICS drivers and binaries for their Tegra 2 and Tegra 3 line early next year?
coolnow said:
Great news! I'm sure none of us will be stupid enough to ask for ETA's!
I'm assuming no HW Acceleration and the good stuff. Have you heard about Nvidia's plans to release ICS drivers and binaries for their Tegra 2 and Tegra 3 line early next year?
Click to expand...
Click to collapse
actually is really smooth, the issues are on other things, im not gonna go into detail, but is def very nice and smooth
There you go! Now all ICS on Atrix speculation can be laid to rest!
samcripp said:
actually is really smooth, the issues are on other things, im not gonna go into detail, but is def very nice and smooth
Click to expand...
Click to collapse
So you saying hw accel or no hw accel?
sent from a galaxy far far away.
maybe idk, just got it today, sure feels hw accelerated, any ways, no more questions
samcripp said:
maybe idk, just got it today, sure feels hw accelerated, any ways, no more questions
Click to expand...
Click to collapse
Thank you for the input mate. I'd get ready to go into hiding if i was you I can just rest easy now
As always, thank you and the Atrix Dev Team, and all the other devs who work on this phone, thank you, thank you, thank you so very much!
;19986019 said:
So you saying hw accel or no hw accel?
sent from a galaxy far far away.
Click to expand...
Click to collapse
How about some Android graphics true facts?
• 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 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 " 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 1280x800 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.
On a side note, the Tegra 2 does not have NEON instructions and only uses single-channel memory, which limits how well GPU acceleration helps with smoothness.
thanks.
sent from a galaxy far far away.
samcripp said:
maybe idk, just got it today, sure feels hw accelerated, any ways, no more questions
Click to expand...
Click to collapse
Sure would love to see a screenshot or 10. Have seen absolutely zero anywhere else about this happening.
Not saying "prove it" or anything, mind you! Just curious (as is everyone else here).
It's great to know that ATrix CM9 is in the oven. I personally have no doubt that ATRIX will get ICS officially.
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.