The Care and Feeding of the Android GPU 307
bonch writes "Charles Ying argues that Android's UX architecture has serious technical issues because, unlike the iPhone and Windows 7, Android composites the interface in software to retain compatibility with lower-class devices. Additionally, Android runs Java bytecode during animation, and garbage collection blocks the drawing system. Google engineers dismiss the desire for hardware-accelerated compositing and cite more powerful hardware and an avoidance of temporary objects as a solution to the collection pauses, but Ying argues that will just lead to [a lower] average battery life compared to devices like the iPhone."
I've complained about this more times than i care. (Score:2, Insightful)
the interface never seems as polished without hardware acceleration, Just look at Mesa and a full linux desktop running ATI or Nvidia drivers with compiz.
Doesn't Optimizing for GPU Exacerbate Fragmenting? (Score:3, Insightful)
Look at Samsung's Galaxy S browser. GPU accelerated and tile-based. I’m told it’s a result of Samsung’s PowerVR GPU optimizations.
Doesn't that require that the device have a PowerVR GPU on board? What about devices without PowerVR like the NexusOne, does it run on that?
When you optimize to GPUs, you have to optimize to all GPUs. I realize there are common instruction sets but the main selling point of Android is its versatility. If I start coding for only Snapdragon processors with PowerVR GPUs because it has a better UX, then it sort of destroys any benefit I get from Android and I might as well code for iOS because I know what that hardware will always be. A lot of the benefits of Android applications being Java byte code completely independent of the hardware are overlooked in this proposition.
The developers don't know what future devices are going to use for GPUs or their instruction sets. From one of the links Romain says:
New devices might allow us to overcome the past limitations that made GPU support a not-so-good solution.
Doesn't optimization for particular hardware exacerbate their issues with fragmentation?
Well, it's open source, there's always the smug answer that Charles Ying can go fork Android himself and add this and watch all the handset manufacturers flock to his side. If you think it's best, get a team together and do it.
From Ying's article:
Wake up, Android team. Windows Phone 7 just lapped you [anandtech.com].
Can anyone tell me why that AnandTech article from March is evidence that Windows Phone 7 has lapped Android? And why it just happened?
Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (Score:4, Insightful)
There is this new thing called "conditional compilation" which allows one to include code that both optimizes for certain hardware and contains generic code that could work on all devices. I hear it's the new rage of how you make code work on multiple hardware and software platforms.
Re:Java, the original sin (Score:2, Insightful)
A shoddy workman blames his tools.
And a great workman knows that certain tools are shitty and worthless.
Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (Score:5, Insightful)
Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (Score:5, Insightful)
You mean it's like a real, honest to goodness, computer operating system? Oh no! The horror! Guess you should stop making software for Windows, Linux, and OSX then, since the hardware can provided different capabilities for systems using the same operating system!
Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (Score:5, Insightful)
Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (Score:5, Insightful)
That depends on the optimization and how that chipset actually handles throwing stuff on the screen. 'Optimize' may not just mean "format the data this certain way and it'll fly through the processors more quickly", it could also mean "use more polygons and lower-res textures because the chipset is better at moving verts around than filling texels". It doesn't matter that it's not low-level if it affects how the whole engine works.
Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (Score:5, Insightful)
Re:And yet, somehow, it's WORKING!? (Score:2, Insightful)
Pretty bad actually. Considering we've been using APIs that allow hardware acceleration with fallback to software implementations like OpenGL to handle JUST THIS EXACT PROBLEM for the last 25-30 years, I'd say it was absolutely shitty for Google to fuck up this badly.
Of course, perhaps thats cause I understand the problem as stated where as you're comparing service providers. You're obviously a fan boy since you're trying to sell everyone on how awesome it is to buy Android devices.
As far as saying what I want, well, once the hype dies down which has already started, and more and more people start complaining which is already starting, it will suddenly become clear that the holy grail of smart phone OSes really isn't better than any of the others and has its own unique set of flaws ... just like all the others.
Funny thing is you can do the same thing with an iPhone as far as upgrading for less than $300 and getting all the crap you posted as features for it ... its funny that you mention facebook ... a website ... that any phone with a browser can get too.
The only advantage you offered was the $50 service fee, however, having been a MetroPCS customer, I can honestly say you get EXACTLY what you pay for. If you never leave your city, it'll kick ass. Those of us who occasionally go outside of the 8 square blocks that Metro PCS covers in a town need something a little more useful.
Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (Score:5, Insightful)
massively different user experience on different devices
consider: different user experience on massively different devices
Why should it be otherwise? Should a quad-core i7 SLI provide exactly the same 'user experience' as an Atom netbook? Obviously not. It is not reasonable to expect the same results from increasingly diverse hardware. Android will be found on the lowest end freebee 'smart' phone China can make, while also appearing on the most outrageous hardware that doesn't present an immediate fire hazard. Where, exactly, was it written that the limits of one must apply to the other?
This problem has been solved over and over again. An architecture must exist that provides fall-back software implementations of hardware accelerated functions. When some app performs poorly due to inadequate hardware the user may find some other preoccupation or upgrade to a sufficient device.
What is the problem? At the moment it appears to be Google's obstinacy. This is a losing battle for them; they're creating a differentiating point among the manufacturers because the manufacturers can alter Android, including accelerating stuff with hardware. Marketing will then make claims about how xyz's Android is better than the other Androids because of xyz's special sauce (that may or may not port easily to some other collection of chips.) If the manufacturers don't the users will.
Lets hope Google wises up and deals with the issue properly.