My response yesterday was brief as it was just annoying reading some of the things being stated in this thread. Either people really have no idea exactly what they are talking about or they are spouting off some PR jargon they were taught by a company.
When talking about 'GPU' acceleration of UI elements there are probably tens of thousands of ways to go about it(likely far more then that) all using what would be considered 'full' GPU acceleration and end up with wildly divergent results.
To simplifiy things a bit- at the basic level you can have a set of register values aligned in a grid that matches your display resolution. When talking about something like iOS or Android assign enough of these to cover each screen you have and all you have to do is "slide" where you are reading data from. Silky smooth transitions on hardware decades old.
If you do things that way, however, you run into a couple of problems. One of the big ones is the modern version of parallax scrolling. In very simple terms, the effects of parallax scrolling is why your icons can smoothly scroll on top of your background without it moving, or with it moving very little. Obviously the previous example of how simply smooth scrolling can be accomplished in hardware falls down there. A 1MHZ processor would have more then enough power to handle the previous method smoothly.
Off the top of my head, you could use raster, animate, layer or sprite based effects for parallax scrolling. Each one of these has their own pros and cons, some of them work on a modified version of the above description, some work similar to how GPUs do today(raster) and all of them have their pros and cons dependant on any given situation. All of these can be fully hardware accelerated each with their own strengths and weaknesses(btw- the SNES was composting graphics elements decades before Apple decided to make it a PR catch phrase). All of these, without outside assistance, only deal with static images and layering of them and manipulation of layers in a relative movement to give the illusion of depth(none of them are actual 3D).
That gets us up to covering at least enough to handle the basics of the simplest smartphone UIs. Nothing terribly demanding by any means, the SNES was pulling these things off smoothly decades ago. Then we start to get into the more complicated issues.
Dynamic on screen content. Take a look at the animated icons on the iPhone. If the UI acceleration were as robust as people make it out to be, this should be a very simple task. Instead what we have is a video overlay with the icons layered beneath(honestly a very smart approach to the problem). Doing things this way allows you to have one animated element overlayed on top of your invisible actual icons which are then layered on top of your background. This limits your number of screen elements and makes two of your layers very easy to apply(from a compuational resources standpoint the invisible icons are likely the most intensive). If you were to allow actual animated icons then you would need to break down your layers further and furthermore have them subdivided and recalculated per frame(need to check the render state for each icon to see if the animation has been flipped).
Then we move along to something like widgets. Widgets you have all of the existing work to do, but then you add to that a number of different program states that need to be checked and updated per frame. You have 4 interactive/animated widgets? The render engine needs to send a request for the state of each one of them and then determine the proper state to draw them in before it can start to fit them in to the layers. All of the aformentioned work still needs to be done, but asking for the render state of a program is not something a GPU can do- either you have the program accessing the GPU directly(could be very bad if said program has any bugs) or you have the CPU handle the states and report them(the way it's actually done).
Then you add live backgrounds. There are a few different kinds, but most of them are actual applications offering feedback either through touch or external reporting factors(weather conditions etc). In a 2D UI your background state has to be known before you can start rendering anything else out, so the program needs to be checked for exactly what it is looking to render. Obviously it isn't significant in and of itself, but your computational time has gone from a few cycles to several thousands of cycles in the process of moving from a basic 2D scrolling background to one like we see today on the most flexible UI platform.
It is possible to ditch all of those layers and move to something more akin to a fully 3D interface. The benefits here when you start getting to these levels of complexity can be fairly dramatic- the program is structured to get all the information at once and create a render state for the entire scene. The downside to this is the entry level resources to run such a setup are significantly higher on the GPU end. Even if you do decide to handle things in this way, which approach do you use? Procedural texturing with an interally developed scripting engine for optimizations(most process intensive)? Look up table for most commonly used screen elements(most RAM intensive)? Dynamic texturing using the default 2D UI and layering them in the scene(least speedy, easiest on development and hardware fronts)?
Everything I've written here is over simplified to an extreme level and is just trying to get across the general point, the much bigger issue is that I haven't come remotely close to scratching the surface on all the different ways you can go about handling these items. Everything I discussed above can have all of the graphics elements fully GPU accelerated, and you could be looking at the difference between 1000FPS and 1FPS on identical hardware.
When I hear people talk about how smooth WinMo7 is and it clearly is more optimized then Android it just seems so obscenely assinine. Does WinMo7 have a smooth UI? Absolutely. Is their UI doing anything remotely comparable to a new Android device? Not even remotely close. If that doesn't matter to you, all the power in the world to you. Doesn't change reality. When there is another UI with comparable complexity that runs significantly smoother people will have a good comparison(actually, there already is but noone brings it up), if the UIs you are comparing don't have directly comparable functionality in terms of what they are doing on a visual basis you can certainly put forth that you like a more minimalistic approach with validity, but claiming one is using hardware better or is better developed is just foolish.
Facebook
Twitter