Slashdot Mirror
The Care and Feeding of the Android GPU
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."
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.
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.
Can anyone tell me why that AnandTech article from March is evidence that Windows Phone 7 has lapped Android? And why it just happened?
My work here is dung.
So instead of supporting a wide range of products they should pull support cause in the future all those wasted cycles will lead to an average battery life? In the future...
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.
Can anyone tell me why that AnandTech article from March is evidence that Windows Phone 7 has lapped Android? And why it just happened?
He's talking about the fact that Windows Phone 7 has advanced GPU acceleration built in from the beginning in several facets of the environment. Android doesn't and it's a few years older.
It certainly hasn't lapped it in terms of sales or momentum, but it could. Android has both the advantage and the curse of being more open and versatile - WP7 has the possibility of a more restrained set of hardware differences and can build in more low-level functionality.
I watch youtube on my netbook just fine. It has 2GB of ram and an SSD. WTF are you on about?
Because it's not bad at all. A shoddy workman blames his tools.
Website Hosting
Yeah and now you're talking about a massively different user experience on different devices ... that's really annoying to application developers.
So basically no different than the current situation?
A shoddy workman blames his tools.
And a great workman knows that certain tools are shitty and worthless.
I don't know enough about the Android graphics API, but if it's designed properly it should be possible for the client to always call the same function and the underlying implementation to select the code path most optimized for the platform. Mac OS X has one CoreGraphics API, and it either composites on the GPU or on the CPU depending on what's available. I don't see why Amdroiid can't do the same.
Don't blame me, I voted for Baltar.
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.
You mean like the rage of having your code get more and more complex every time a handset comes out?
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
That's great for those who want it, but how about those of us who'd rather bang closer to the metal?
Belief is the currency of delusion.
My netbook may only have 1 GB of RAM, but I watch Youtube, Hulu and Netflix on it in standard definition, no real troubles?
... "I read part of it all the way through." -- Movie Mogul Sam Goldwyn (and some slashdot readers)
A shoddy workman blames his tools.
Unless the tool is the thing that is shoddy.
Surprisingly perceptive for a troll......
until the iphone came around RIM and others would have low end, mid and high end devices with different hardware. i've even seen dumb phones run java. it allowed hardware makers to have a ton of devices out there for every niche and cut down on dev costs. Java was cool since you only write the app once.
then the iPhone came and killed that model. the cost of the iphone is something like $2200 over 2 years. Droid is about the same. any other smartphone on AT&T or VZW will be within $200. i tell people to get the best phone they want since the cost is negligible over 2 years.
Even the less bright execs are starting to realize that there is something stinky about Java, the problem is that the average IT exec is still somewhat brainwashed by the original Sun's marketing and ploys, the clever namings of things. For example the pesky buzzword "managed code", any software exec loves that phrase, unfortunately running "managed code" is usually disastrous on a low-power and inefficient mobile platforms, not to mention any time critical or performance applications that can't cope with execution stalls and uncertain memory conditions provided by the dreaded "automatic garbage collection".
And an idiot workman pounds nails with a pile driver.
OS X uses llvm just-in-time compilation in the graphics stack. If the hardware supports it, it's sent to the GPU. Otherwise, it's done in software. Since android is based on dalvik, they shouldn't have a problem doing something similar. Sure, they need to support cheap pieces of shit, but that doesn't mean they can't support anything else.
Do you even lift?
These aren't the 'roids you're looking for.
You mean like the rage of having your code get more and more complex every time a handset comes out?
So basically the situation that already exists. All these new devices tend to need new drivers added to the kernel and they usually do some sort of tweaking to the kernel. Seriously, if they can't handle complexity then they shouldn't be the ones maintaining and developing an OS. Such work is just inherently complex.
Waiting for better hardware
That was the very purpose of inefficient Java.
(to sell Sun's 'better' hardware)
Smartphone and no GPU? That is not a smartphone in 2011.
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!
You don't need to optimize for all of them. Go ahead and pick some of the more popular ones that already exist and optimize for those. Manufacturers are still free to choose different hardware or write their own code, which they are perfectly free to do being that Android is open.
Having a few 'better' options isn't going to be worse than the lowest common denominator crap that's going on now.
Yeah, that Android platform is barely working at all, huh? Might as well fold up the tent. Stupid execs.
Or maybe you're trying the old "if it doesn't work for everything, it doesn't work for anything" ploy? I can't tell, I have a hard time deciphering which particular stupidity you people get up to at any given point.
And in this case the particular programming language, Java, is shoddy.
A shoddy workman blames his tools.
Unless the tool is the thing that is shoddy.
A particular hammer might be shoddy, but hammers in general are not. A good workman might blame a particular hammer, and switch to a different hammer, but only a shoddy workman would blame hammers in general, and starting hammering with a crowbar.
Of course, the OP might be suggesting that Java on mobile devices might be like using a sledgehammer for hanging a picture frame. I'm not sure I agree with that assessment, but your rebuttal is a straw man argument.
The CB App. What's your 20?
OMG Android is making a play that's designed to let lower cost, highly capable devices subsist in the marketplace? How horrible is that?
I switched from Evil Major Network (TM) to Metro PCS a little over a year ago, and haven't regretted it for a SECOND. It is so nice, getting what you paid for, rather than wondering how much you'll be overcharged for what you aren't even sure you got... it's the ONLY way to survive teen children!
And even Metro PCS, the low price leader, offers a couple of Android phones that are highly capable and useful. For less than $300 I was able to upgrade my wife's shatty phone with a nice, capable Android phone with GPS, navigation, browser, email, games, full-screen youtube, Facebook, Marketplace et al (AKA "the works") and a good, full day of battery life. She LOVES the phone! In case you are wondering, it was the Samsung LG Optimus. And the network cost went from $40/month to (gasp!) $50...
Talk about having your cake and eating it too?
Say what you want, Android's strategy is working, as demonstrated by its continuing skyrocketing market share.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Somebody should really invent a programming interface for graphics. You could use hardware or software rendering for the same code, or generally a mixture of both, depending on the capabilities. It could be called "open graphics library" or something.
Escher was the first MC and Giger invented the HR department.
Java may not make as much sense right now, but it will again in the future. Technology is going to keep marching on and today's smart phones are tomorrows feature phones and eventually dumb. Not all apps will need to be more sophisticated.
Android is going to get even more fragmented in the future, but that's not a bad thing. It just shows how versatile Linux can be.
Debian seems to handle it just fine and (based on gcc) they're compiling for 14 different platforms* and 3 different kernels (linux, hurd, freebsd)
Is it that difficult to setup a similar thing in the app store? "Oh it looks like you're running an ARMv5 and a PowerVR GPU. We'll give you this binary."
Or, you do what Apple has always done with Fat Binaries. 68k to PPC. PPC to PPC64. PPC* to i386. i386 to x86_64. You could have one single fat binary that supported ppc, ppc64, i386 and x86_64. And it "Just worked". They were literally checkboxes in XCode. How many GPU and CPU solutions are there for the Android? This isn't low level Assembly code, it's compiled Java.
*alpha amd64 armel hppa hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 m68k mips mipsel powerpc s390 sh4 sparc sparc64
Let me tell you one thing about that: Java isn't the problem. In my definition of feeding the GPU: triangles/sec, fillrate and OpenGLES objects/sec, Java is just 10% behind a raw C benchmark like glbenchmark 1.1/2.0. They quoted 880kT/s, I managed 750kT/s in non native code. And to get that, you have to carefully feed the GPU with the right batch sizes, don't issue too many state changes, pack things interleaved in the video buffer, don't use dynamic point lights, etc etc. It isn't as bad as an NDS, but the Snapdragon GPU is quite hard to tame.
The problem with using the GPU is that every context switch requires a complete reinitialization of the GL context, even on a PC, alt tabbing into and from fullscreen games takes ages - it's fine when specific applications which requires the speed use it directly, but it's not when going from one activity to another gives you a loading screen.
Animation performance and touch responsiveness? Is that the best he can come up with for such a title? I have no idea what he's talking about, but scrolling the browser works just fine here on a not-so-recent HTC Desire. The only time things break down is when the garbage collector halts everything for a third of a second (see DDMS/logcat messages), and those pauses are reduced to sub 5ms in the new builds. That's tons more useful than rendering surfaces to quads and using OpenGL ES to draw them, and IMO, the Android team made the right decision.
It seems like something like Meego (Linux+GL+Qt) would be the best way to go, if you are not an Apple device.
I never understood why anyone would want to interpret byte-code on a battery powered device. Or give up control of garbage collection. Maybe the VM enforces things like local file system access, but a few lines in the kernel can enforce that too.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
Java failed on the desktop because it tried to do too much and failed to provide a consistent, native-like user experience.
Dalvik on Android provides a very consistent, native experience because the platform is built around it.
And it provides a level of abstraction away from hardware that allows an Android app to run on any number of Android devices, if it's well written (i.e. can handle different screen resolutions, etc. - if you hard code tons of shit, you can still write apps that suck or don't work well on certain devices).
So yeah, in this context, there's nothing wrong with Java (or rather Dalvik). As to the question of the best way to accelerate basic UI stuff - I sort of thought this issue was already solved on the Android platform.
Yeah, first gen Android devices were stutter-y and had kinda laggy feeling UIs (i.e. the G1 - ugh). But my year-old Nexus One running a recent MIUI ROM is as smooth as butter in terms of touchscreen sensitivity, animation, etc.
Likewise with my Viewsonic G Tablet running on a hot-shit Tegra 2 - with the updated drivers and software on it, it's ridiculously smooth and pleasant to use - better than an iPad any day.
Furthermore, I understand that Gingerbread has even more improvements in GC and event handling stuff, so should be even better things ahead.
Does the original story's argument about battery life hold up? Maybe, not sure. My G Tablet's one weak area, compared to the iPad, is battery life. One hardware-accelerated tasks like video playback they are comparable. But in terms of app-running and general usage, and particularly standby time, the iPad definitely wins out. But the Tegra 2 platform is fresh, to say the least - have to see how the drivers, suspend-resume and so on improve over the next few months. Battery life may improve quite a bit yet.
Symbian^3 also needs a GPU and has very good power management and doesn't support older hardware ... oh, but wait, this is Slashdot....Symbian bad and old fashioned and hopeless...Android good.....
This is all just my personal opinion.
Well, as expected, Android is targeted at average mass consumers, so average battery life is acceptable. What gives?
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.
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
Add to that, you really don't need to optimise the code that you use for compositing on the GPU. A low-end mobile GPU can render something on the order of three million textured triangles per second. A typical mobile UI has a few dozen UI elements, with one texture and two triangles (one square) each. Even really crappy code is not going to come close to taxing the GPU. That's why we do compositing on the GPU - because it can run in its lowest-clocked mode and still provide fast performance, which lets you use the CPU for something else (or down-clock it too and save battery life).
I am TheRaven on Soylent News
No, that one game everyone talks about doesn't count; it's not a result of OS fragmentation, but a result of some devices not meeting minimum hardware requirements.
What do you think fragmentation is?
What I find funny about this argument is that the same group of people claiming fragmentation will never be an issue is also the same group of people that claims that PC games aren't as good as they could be (graphically) because they cater to the lowest common denominator.
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
and cite more powerful hardware and an avoidance of temporary objects as a solution to the collection pauses
LOL.
Java is pretty much only GC language I'm aware of where temp objects are passed to GC. Perl (and I'm sure myriad of other GC languages) at compile time takes note what objects are not used outside of the context and destroys them immediately. IIRC Java is the only language where they blankly send all stuff to GC, regardless. Obviously that that in long term hurts latencies: GC has to recycle them eventually and if there is no spare CPU/core, then it has to take the time from other threads.
All hope abandon ye who enter here.
Actually, it is. Garbage collector stalls have been a problem that has consistently plagued Java for as long as it has existed. Those of us who have been around long enough still remember Java apps hanging for tens of seconds at a time while the garbage collector ran. These days, the user would force quit long before the app came back to life if an app were to hang that long. It isn't nearly as bad these days, of course, but on a slow CPU, it can still be a problem. That is why Apple wisely chose to use explicit memory management instead of garbage collection when designing iOS. Garbage collection means choosing rapid application development over performance, which can be an acceptable tradeoff on the desktop, but is rarely an acceptable tradeoff on a small mobile device with limited CPU performance.
You're right. A good workman, upon determining that the tools are bad, throws them out, gets better tools, and then goes back and fixes whatever he/she screwed up with the old ones.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Have we not learned anything from the desktop ? In 2011, as an app developer, you shouldn't be optimizing for any specific GPU. The platform's graphics API should be optimizing for whatever hardware it supports. New device ? New drivers! If Samsung's PowerVR implementation makes such a big difference, then we will see other hardware designs adopt the PowerVR. You don't need to reinvent the wheel every single time. Media-minded people will favour devices with faster GPUs, just like we do with PCs.
I'm only tangentially exposed to Android, but what I've seen so far is an already inconsistent hardware panorama. It seems no two manufacturers support the same version of Android, which leads to situations like today where the Samsung Galaxy S is leaps and bounds above all others. Adding proper GPU support will only widen that gap. As consumers, we benefit from developments that embarass the shitty manufacturers and goad them into releasing better hardware for the money.
And on a more lateral-thinking level, if you're a fan of Android, you want them to pull together and release something that can adequately compete with iOS and Windows Phone 7. Allowing mediocre hardware manufacturers to completely undermine the OS design is not the way to beat Apple.
-Billco, Fnarg.com
The language itself has 0 to do with its speed. As for the JVM, well Android uses the Dalvik VM. As for whether or not it is fast, there is really no technical reason it would be any slower than any other byte-code interpreter (eg. .NET). So, given that, I take it you have a problem with any sort of bytecode, preferring only natively compiled software? That kind of goes against the hardware agnostic nature of Android, doesn't it? What would you suggest that an OS, whose major feature is cross-device compatability, do?
no android based system will ever, ever be as great as the iPhone. clearly it is foolish to even dream of such a thing.
what is becoming more and more obvious with each passing month is that nobody cares. Android is outselling everything else by an ever increasing margin.
-Lod
It sounds like the Google engineer is taking the sane approach. He is trying stuff and testing the speed. Sounds like he'd try GPU if it helped.
Is there some reason people continue to think Java is a good idea in handhelds? It's almost a religion, and no amount of dissuading seems enough to change people's minds.
Probably because for the mobile market, a managed environment and relatively easy hardware compatability trump performance as concerns.
Which doesn't make you feel any better when an app runs like crap on your phone, but, there it is.
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.
Lurking at the bottom of the gravity well, getting old
Nice try. You slipped in the phrase "OS fragmentation" when what people refer to is hardware fragmentation, which is what the last part of your statement is describing.
At least a sledgehammer is an actual hammer. Using Java on a mobile devices is more like using a whale to hammer in screws.
I find it funny that the article mentions Galaxy S, and the browser from the recent JPU/X/Y firmware. I've used the JPU/Y browser on a day to day basis, and it's horrible. Pinch-to-zoom is very smooth, and the tiling isn't really an issue, but the page sometimes gets very distorted when panning. I haven't noticed any improvements when scrolling, it's choppy as it ever was. The JPU/Y browser has made me even consider changing to Opera/Firefox/Miren or something else as my day to day browser.
Sent from my Galaxy S i9000 running XXJPY and voodoo.
You mean desktop computers, those complicated machines that mobile devices and tablets are replacing? People are trying to get away from managing device drivers and hardware compatibility bugs.
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.
Yes
That's why Apple uses LLVM to compile from 'generic GPU code' to 'GPU code optimized to Blah', that's on Mac OS and maybe on the iPhone as well
http://llvm.org/Users.html
how long until
Try running Skype videoconferencing on you netbook. On an MSI Wind, Skype complains the CPU is too wimpy. Low resolution YouTube is hardly a good benchmark, it runs fine even on a Android G1. Compressed video decoding is much less CPU-intensive than compressed video encoding.
I've abandoned my search for truth; now I'm just looking for some useful delusions.
What about the collector pauses?
Actually Android does not use Java bytecode at all.
Java is the language used to program for Android, but the code compiles into Dalvik bytecode. There is no J2ME support at all, or any Java virtual machine on the device.
http://en.wikipedia.org/wiki/Android_(operating_system)#Features
Look at Java Support.
It's easier to fight for one's principles than to live up to them.
Speaking as a former Googler, the smart people spin is somewhat overrated. Arrogant people is closer to the truth, and "smart" tends to mean "good at avoiding work".
Have you got your LWN subscription yet?
Great, so you want another pile of suboptimal backward compatibility to win rather than a well engineered solution?
If you want your software to run on really cheap and nasty hardware you have to make some pretty unforgivable software compromises. At least Microsoft, Apple and others have standards.
Will win what? What constitutes victory? Does "winning" mean that something else "loses"? What does "lose" mean in this context? Apple makes more money off of their minority share of cell phone sales than any other company. Their share of the total profits on PC sales is over twice their market share. Is that winning or losing? Microsoft makes even more money (for now) with higher margins and they haven't done much in terms of new products in a decade. Are they winners or losers? The largest device manufacturers whether PC or phone have minuscule profit margins per device. They have to sell millions of these things to stay alive. Are they winners or losers? If Android ends up on 60% of all smart devices and the vendors who make and sell them account for only 30% or less of the profits, are they winners or losers?
Very often, people confuse simple with simplistic. The nuance is lost on most. - Clement Mok
If you say so, true believer.
How does it show how versatile it can be? Running with different hardware capabilities isn't something operating systems haven't done before. It is a bad thing because it increases development and support costs for app developers and forces bugs and design compromises onto consumers. There's a reason consoles and mobile devices are replacing desktop PCs in most people's lives.
So some random person on the Internet who doesn't appear to have much to do with Android points out a couple of not-really-problems, and suddenly everyone is supposed to drop everything and fix them?
If you search for "charles ying android" every link comes back with a reference to this single blog post. I could take him seriously if I'd ever heard of him in the context of Android development, or even at all...
I never understood why anyone would want to interpret byte-code on a battery powered device.
Allowing hardware diversity, while still providing a single binary (VM) interface to apps, might be a good reason.
People are trying to get away from managing device drivers and hardware compatibility bugs.
Maybe I'm just weird, but that's not why my desktop and laptop computers have been getting lonely lately. It's because my mobile device is, you know, mobile.
MCSE? No, sir...I don't do Windows. Yes, I am an idealist. What's your point?
Hmm, let me check, nope no one mentioned that, so I fail to see why it matters. If I want to use skype I do it from the nice beefy HTPC and use the nice camera there too.
Yet perl does not have that problem. Almost as if GC is not the problem, but the particular implementation is.
As opposed to what? Python? Ruby? PHP?
Unless you want to get down and digging into mallocs Java works just fine. And as long as your little tetris clone doesn't depend on spring webapp supplying the board representation each frame to canvas via CORBA on localhost (can be done, can actually be done...) will probably won't differ all that much from what can be done by writing the app in assembler.
And if you really are incapable writing code that doesn't feed off heap constantly - you can develop in C on android as well.
No. You only take the complexity hit on the second device.
The rest rely on the well known and well used methodology for dealing with diverse hardware you've already constructed.
It's like the 80s and 90s never happened or some such.
"mobile" doesn't change any of the problems.
A Pirate and a Puritan look the same on a balance sheet.
Hmm. I guess the fact that java* has been working just fine on mobile devices from a decade ago bears no relevance to discussion I guess?
Can we please stop mixing up the java APIs (and some of them do contain horrible bloat), "libraries" (but nobody really forces you to build your app around that 30MB OpenGL/DirectX software renderer), and the language itself (that allows to implement memory-copy-less networking stacks, in example, and once you've cleaned your critical execution paths from needless memory allocations (just like you would do in C/ASM) runs like a charm)?
*J2ME - java w/o reflections and with a trimmed down API.
Don't blame java for that...
Speaking as a former Googler, the smart people spin is somewhat overrated.
And you say that as an unbiased observer with no axe to grind, right? :-)
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
If success of the sub-optimal solution prevents the ascendancy of a monopoly even worse than Microsoft's then HELL YES.
Of course pointing to either Apple or Microsoft as the "savior" here is a fallacy. Each has it's own problems, even at the "engineering" level.
A Pirate and a Puritan look the same on a balance sheet.
"mobile" doesn't change any of the problems.
No, but 3D does. But I guess the people following gaming aren't the same people that follow 3D development on handheld devices.
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
Well, how about not allocating memory left and right then? Of course you'll need to spend a little bit more time to get it done nicely, perhaps think ahead a little bit and preallocate some memory where you'll need it, perhaps jump down to actually couple of arrays of primitives, etc... Almost like if you'd be using a 'proper' tool...
And still have a choice to quickly throw together those parts of app that are non-critical to users experience.
If android was implemented in 'proper' low level stuff, we would still be looking at version 1.5.3.
If one is incapable of writing Java/Dalvik code that runs well then I pitty the C code they will churn out.
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
And you say that as an unbiased observer with no axe to grind, right? :-)
Right. I still own all my Google shares. However I am now properly disillusioned about a number of Google myths, but don't trust me. Ask any Googler, former or otherwise. In the latter case, make sure to do it out of earshot of other Googlers.
There are smart people at Google, and if they are really smart they learn early to keep their heads down. This seems to be the main sequence for large tech companies. Microsoft is far advanced on that path and Google seems more than a little determined to follow. The stack ranking system is nearly a carbon copy of Microsoft's, which in turn was copied from GE, and look how well that worked out. The result is inevitable degradation of the engineering culture. Now, warning about the negative consequences is not the same as axe grinding, quite the opposite.
Have you got your LWN subscription yet?
possibly not, Symbian devs have worked with C for years on all sorts of chipsets. They squealed more about rewriting their code in Java than cross-chip compiling.
Most Androids come on a few chip architectures anyway (or are they all ARM based?), and the API provided by Google would be standard so I can't see much problem with cross-compiling for all known Android devices. Hell, you could set up a build server in the app store so when you uploaded your code, it would auto-compile for all devices Google knows of. And it would optimise each for the particular platform - that would be a good option, IMHO.
People are writing code for Android using C++ and Qt, so they must be handling the cross-platform problem somehow.
On Mac, it's called CoreGraphics.
On Linux, it's called QPainter or Cairo.
On Windows, there are so many APIs that I don't feel like naming them all.
Android's graphics stack with the policy "let's do everything in software" is possibly one of the worst features of the platform. Most smartphones are capable of at least OpenGL ES 1.1, if not 2.0... and if you don't care about 2.0's features, there's only one API your compositor needs to implement to support ALL of the mobile GPU's out there. How's that for fragmentation? Of course, on dumb framebuffer phones, you'd probably want to implement a software fallback, as most software OpenGL ES implementations would probably be slower.
So Android needs two compositing backends then... how sad for them. Seriously, the fact that I need a 1.2ghz Cortex A9 to smoothly scroll though a list of icons is just pathetic. I mean, a NES can do that at 60fps... the magic of hardware acceleration.
I believe the original answer to "java in handhelds" is "java is safe". Back when running apps on your cell phone (and color screens and polyphonic ringtones) was a novel idea the phone makers were afraid of runaway apps.
I still believe that security is the original reasoning why apple did not allow third party apps on iPhone at the beginning and only opened tightly controlled store a year later - it's an alternative to java. Now there's more politics than technical reasons.
I can be wrong tho.
Thanks. I just found 2GB netbooks
do exist. What you own is as good as experimental until it is easier to find on shelves; reminds me of the topic of the Google Nexus. It was just as hard to locate out in the wild in users' hands.
Meanwhile, here is the projected price of your device in 2009 ($350) and here is how pricewise ($728) it is just it is piled together with the laptop category.
Americansand their shitty mobile market. We (Europeans) buy phones... and we buy mobile communications packages...Two different things... When you say "iPhone is $2200 over 2 years", it sounds very ridiculous to me... if you have plan that costs you $2200 over two years, then or you talk to much on phone to justify that price or you're dumb... Buy a fucking phone... then subscribe to whatever plan that fulfills your mobile communication needs... and not more then that...
How about ARMv5TE and ARMv7-A?
The 1GB barrier is an Intel/Microsoft business decision requirement to allow selling of WinXP/Win7Starter at a reduced cost. It was never a technical issue.
I don't have an android phone so perhaps someone can inform me if I'm in the wrong here... but I would assume that the android store has some sort of filtration system that doesn't show games which require a touch screen to users of phones without touch screens. Games that require serious power would similarly be limited from lower end phones. I can't imagine all of the apps currently in the Apple app store work on the original iPod touch/iPhone. I can see how it might be disappointing for someone with a cheap/old phone not to be able to use the new whizbang app someone else has, but I would also assume there'd be some expectation of not being able to do "high-end" stuff on your "low-end" phone. *shrug*
Check out my lame java blog at www.javachopshop.com
Ying argues that will just lead to an average battery life compared to devices like the iPhone.
I really don't understand statements like this. It's obvious from statements like this that Charles Ying has a personal vendetta against the Android platform.
I think what he's meaning to imply is that battery life for Android devices tends to be both mediocre and highly variable in comparison to the iPhone.
By implementing the "average" weasel word (most people thinking average = bad), he is really trying to taint the whole platform.
I thought he was trying to be conciliatory and avoid alienating Android fans. By pretty much all proper studies, Android devices tend to do very poorly on battery life when running an average number of third party apps (as compared to iPhones). Take a look at some of Michael Arrington's writings on the subject (he writes for Tech Crunch and is a very outspoken Android fan). Several Android loving reviewers have brought up this point and demonstrated it, but maybe it needs to be said again: Battery life is Android's Achilles heel. The performance can get really, really lousy largely because of the poor performance and design decisions of third party app makers. The big problem for the average user is, they don't have easy visibility into this. They don't know their phone sucks down the juice because they installed a crappy game that is constantly contacting a server to look for updates or new ads. More expert users can use an app to profile battery life, but that doesn't really help phone makers who are the ones losing sales over it.
...my pea brain parses it similar to: "An Android phone has battery life +/- 5% within the working range of a comparable iPhone
With a good phone that has an up to date version of Android and where you're careful to pick your apps based upon battery usage, this might be the case. If you're a normal user that just downloads some apps and uses whatever version of Android is supplied with it, well I seriously doubt you'll get anywhere near that close.
Self professed Android phone lover Tom Loverro puts it thusly: "Battery life is not just another feature on some specifications checklist. It is the driving philosophy behind every design decision made on the iPhone. I think Android fanboys totally miss this point." He goes on to say, 'producing a great phone that gets six hours of battery life, is like me saying “I love my pet tiger, but he eats babies.'"
Just to add: I payed $500 for my android(the same thing is also true for an iPhone) smartphone upfront... then i pay an average of $10 of calls/SMS plus $7.5 for a mobile internet package... I would be very dumb to subscribe a $2200 plan over two years just to get my phone for free... $2200 is roughly $91 per month, I bet most(like 90%) people don't have the need to spend over $90 per month of mobile communications...
Look at WDDM 1.0 in Vista and to a lesser degree WDDM 1.1 in Win7. It fucked up 2D big time. I didn't see anyone warn me about the design flaw that WDDM was, either.
[appleinsider.com]
Yeah, I'm sure we'll find a nice, unbiased presentation of the "issue" in there.
That Apple seems to honestly believe Android's supposed "fragmentation" is a disadvantage versus their complete integration shows a remarkable inability to learn from the mistakes they made that cost them the desktop. Watching Android march past iOS is like watching the 80s and early 90s play out all over again.
OpenCL is using GPU for tasks that are normally done by CPU. The problem at hand is exactly opposite: CPU is doing stuff that GPU should do. OpenGL is the solution.
Java2D? :-)
But how is that any different than the massively different user experience between the iPad and a Touch and an iPhone 4? Rovio's popular Angry Birds game has more choppy animations on the iPad than on some of the unsupported Android devices, btw.
On Mac, it's called CoreGraphics. On Linux, it's called QPainter or Cairo. On Windows, there are so many APIs that I don't feel like naming them all.
lol...open graphics library
Why those over the stock browser? I haven't really tried any of the others, never had reason to. (Although I played with Dolphin because it had pinch/zoom earlier). I have an N1, btw.
-]Phreak Out[-
I have an HTC Magic phone that I just upgrade to Android 2.1-update1 (2.6.34 Cyanogenmod). Obviously this phone is years old and first generation. It sports a 528Mhz phone with limited GPU capabilities and limited memory (228Mb or thereabouts).
However, while playing games like Radiant, Labyrinth, X Construct or stuff like that I've never seen it hang because of collector pauses, stutter or anything like that. Home-screen animations are smooth and nice, even with a fish-tank in the background.
However, a phone like this will suffer when CPU usage spikes when an e-mail, text or twitter message is read in the background. I guess it would be easy to confuse one stutter for another in that respect with a device with limited CPU power.
News about the Kettle Open Source project: on my blog
No amount of hardware will fix the problem that android is facing, current hardware is way faster than needed for silky smooth UI.
I'm not really sure but I believe android is using immediate mode graphics for 2D while iOS and WP7 are using retained mode graphics. The advantage of retained mode is that GPU deals with drawing the screen and processor does not have to deal with it meaning that if app is blocked by garbage collector an animation may continue.
Nice try. You slipped in the phrase "OS fragmentation" when what people refer to is hardware fragmentation, which is what the last part of your statement is describing.
No, they mean both. Also, carrier fragmentation and app store fragmentation.
I don't see how you can completely dismiss OS fragmentation, when most handset makers (and carriers) make rather notable modifications to the versions of Android they ship, and often leave their users stuck with obsolete versions.
The rage happens when you install HelloWorld and it fills all available storage.
Actually, that's part of the problem. Google officially preaches memory reuse and non-promiscuous object creation, and the official Android API reflects it, but it's a Java programming paradigm that more or less totally goes against everything everybody who majored in computer science was taught to regard as sacred. I force myself to treat objects like reusable containers & pass them to methods as parameters when writing Android apps, but I still feel kind of dirty and unclean every time I do it, instead of defining a proper local class specific to whatever it is that I'm trying to return and neatly wrapping everything in a purpose-built object (complete with implementation of log4j's ObjectRenderer interface... yeah, I broke down and hacked my own wrapper class to make Android's Logger act like log4j) before returning it.
Qt is compile anywhere, run anywhere. Sure, there is some management of binaries (each platform gets its own) but build scripts take care of this. Scripts then deal with selecting the right binary.
Imagine an app store where you upload your code, it compiles for each platform and it installs the right version to the device automatically. Want AgryBirds for Android? No problem. iOS? No problem. Desktop, no Problem!
One app store to rule them all.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
LOL. You sound like the "IBM guy" in the 80's arguing that the IBM PC-AT will crush the clones due to its obvious technical superiority. Compaq *destroyed* IBM in the PC market, because they realized that great technology can be defeated with even greater business model. In other words, while technical flaws can be fixed, fundamentally self-limiting business models can't. This is not to say that Apple and Microsoft will not continue to be profitable, but that Android will eat their lunch for the same kinds of reasons that other flawed technologies won against their (temporarily) superior competition.
Interesting theory. I've been working with Java since version 1.0 on devices as slow as an embedded 100Mhz device with 128MB RAM and I never remember GC taking seconds.
Just because I'm curious I tried to push our Java application (Data integration engine) to use both CPUs at 100% and dump the Garbage Collection stats to disk. Here's a typical sample:
133,091: [GC 30567K->10559K(60160K), 0,0052000 secs]
133,447: [GC 34943K->10347K(64832K), 0,0036360 secs]
133,873: [GC 39659K->10347K(63872K), 0,0028940 secs]
134,286: [GC 38699K->10531K(63104K), 0,0033140 secs]
134,674: [GC 37923K->10263K(61952K), 0,0019690 secs]
135,072: [GC 36759K->10351K(61184K), 0,0024490 secs]
135,462: [GC 36015K->10339K(60352K), 0,0022610 secs]
135,797: [GC 35171K->10739K(59840K), 0,0039780 secs]
136,134: [GC 34803K->10679K(59008K), 0,0033120 secs]
136,479: [GC 33975K->10567K(58048K), 0,0029140 secs]
136,801: [GC 33159K->10647K(57472K), 0,0026420 secs]
Note that this is without incremental garbage collection enabled. It might be possible for graphics intensive applications to notice the fraction of a second of delay but something tells me that this just might not be the case.
News about the Kettle Open Source project: on my blog
There was such a thing as "IBM compatible" in the '80s and '90s. There no such hardware reference for Android. Apple is correcting many of the mistakes made during that time frame, while Google is making entirely new ones.
In fact, it's extremely difficult to find all that many ways that this *is* like that time frame. The only thing that is similar is it's Apple's platform vs a platform shared among many manufacturers. In almost every other way, there are notable differences.
For example, things like price and features are not downsides for Apple. In fact, Apple quite often is the winner in these measures. And cell carriers distort the market. Watch what happens once Verizon carries the iPhone. I really doubt most Android buyers actually specifically want Android. It's just the nicest phone for the cheapest price on their carrier of choice with the least offensive data plan.
Or put another way, do you think "Android phone" or "iPhone" had the higher place on people's Christmas lists this year?
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!
Yeah, instead you can use the phrase 'lowest common denominator' over and over again.
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
Additionally, Android runs Java bytecode during animation
Except in the real world, where Android uses a non-Java VM with its own bytecode, and doesn't run Java bytecode at all.
What about the collector pauses?
"Me too." I also find that I have to tap twice in many situations to get the phone's attention at all (G2/froyo). Not all that impressed to tell the truth, although I'm much happier with it than I would be with a totally locked down Apple product. But my Nokia music phone has a way smoother user interface and way quicker response. Oh, and a way better loudspeaker, the one that comes with the $500 G2 is quite pathetic.
Have you got your LWN subscription yet?
There's a myth going around that battery life is strongly affected by how efficient your code is. On most phone, it's simply not true. By far the biggest power drains are the screen and the radios (cellular, wifi, bluetooth). On Android, there's even a handy battery monitor built in that you can use to confirm this (Settings->About phone->Battery use). I can spend half an hour playing a high end, graphics intensive game (Hero of Sparta) on my Nexus One, and when I then check the battery use, I find that even while I was playing the screen and the cellular radio standby were still the dominant uses of power.
"I'm too busy to research this and form an educated opinion, but I do have time to tell everyone my uninformed opinion."
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.
All you've done here is just restated the fact that Android is fragmented.
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?
It's written into the license and business model Google chose for Android. Sure, it's not a universal rule, but it is a good rule of thumb. Just like your Atom vs i7 example, most Windows apps aren't written to take advantage of multiple cores, even those that could really benefit from it. So the i7 gets stuck running software designed for the Atom and its single and dual-core ilk. It's the nature of a fragmented market.
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.
"Find some other preoccupation" is not a consumer-friendly answer. The alternative you mention is not as simple to do in a market dominated by multi-year contracts and relatively complex upgrade procedures. It's also very difficult to know which device to even upgrade to! It's not like PCs where you can say, "well, this game needs a 5770 and a Core i5 quad" and you can just spec out an upgrade to give you that. It's more like, "this app is slow. which phone can run it better?", which will leave most consumers confounded, and they will be forced to opt for the "find some other preoccupation" route, which is going to really sour their experience.
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.
How exactly do you expect this to work out in the real consumer world? How are people going to know which Android phone is faster/better than the others? It's like that checkout lane story from a couple weeks ago. No matter what you choose, you likely didn't choose the best one. Normal people aren't going to put in the effort to keep up with the latest Android news.
Lets hope Google wises up and deals with the issue properly.
They won't. It's essentially impossible to properly deal with this issue, because it's inherent with the very thing that has been so valuable to Android. The openness that allowed Android to spread across so many handset makers has to deal with the effects of being available from so many handset makers. You can't have your cake and eat it too.
Not sure what country you live in where an iPhone or Android phone costs $2200 over two years!
doesn't show games which require a touch screen to users of phones without touch screens
Luckily, a touch screen is a requirement for Android (although no specifying the quality of the touchscreen), so that's not a problem. And yes, the Market does have a filter in place to only show apps that can run on your phone. Not sure about performance differences, but certainly it filters for hardware features (e.g, cameras, screen resolutions) and OS versions...
That's because Perl doesn't have garbage collection. It has a half-assed approximation at implicit reference counting, which is pretty much the worst possible scheme you could construct. It doesn't hang because with the exception of simple data types, it rarely actually releases much of anything unless you go to a lot of trouble to force it to do so. Complex data structure? No problem. Just be sure to mark exactly the right subset out of all of those thousands of cross-references as "soft" so that it actually gets released at the right time and doesn't get released early. Otherwise you either leak memory like a sieve or get incorrect behavior. Alternatively, you can write manual destructor code that zeroes them all. Either way, Perl's so-called "garbage collector" is the essence of hell.
Having written code that deals with lots of large objects in Perl, let me just say that I'll take the memory management scheme of pretty much any modern programming language over Perl any day of the week and twice on Sunday, where "modern" is defined so broadly that it even includes ANSI C or Pascal. Even Java. And I really don't like Java.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Bloody hell that's difficult to read. Since you're obviously new to the internet you should be aware that using caps generally denotes 'shouting', try reading your post with that in mind and see how ridiculous it sounds.
Ummm, that would be an example of hardware fragmentation, there.
I don't think you can. In the example of J2ME, the ideas behind the language may be fine, but if you have to run it on a bunch of low powered devices, each with their own, different, buggy version of the API, its not going to be a good thing.
How does it show how versatile it can be? Running with different hardware capabilities isn't something operating systems haven't done before.
Show me another operating system that rules both the top 500 supercomputer list and the smartphone market, not to mention many other segments.
Have you got your LWN subscription yet?
I'm running Dolphin HD mostly for better tabbing support, and the ability to download any file (including those I don't have an app for). I know the latter is a feature of Astro File Manager, but I use Root Explorer for my File Manager, and don't really want Astro.
Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
It seems like something like Meego (Linux+GL+Qt) would be the best way to go
I would be a lot more excited about Meego if it didn't use rpm for package management. While there is not much difference between rpm and deb capabilities technically, deb repositories tend to be a lot better put together and maintained. I use both on a regular basis.
Have you got your LWN subscription yet?
The USA.
I think your joke went over most people's heads (your post is modded Insightful instead of Funny). For those who are wondering, the answer is OpenGL.
Better throw in some XML for good measure...
Couple problems here. First, we're talking about mobile devices here. Yes, you can get a 32GB microSD for your phone, but it's expensive, and most people aren't going to have one yet. Fat binaries would take much more space on the memory card, and more bandwidth to download (watch those caps!), which makes it infeasible. As to having the app store give you a binary for a specific hardware setup, that would be asking thousands of tiny, independent app developers to try to maintain and compile their code for that same array of architectures, which would likely be sufficiently problematic that many of them would simply stop developing, or would only target their preferred architectures, further fragmenting the app market.
There is absolutely a hardware reference for Android. It requires a CPU based on the ARM11 or newer architecture, at least 256MB of RAM, at least so much (not sure on exact numbers, "enough to fit Android + system Apps") flash storage, and a touchscreen. That's the same as saying "IBM compatible," which really just meant "80286 or better CPU, enough RAM to run DOS, a screen, and a keyboard." The inability to run Need for Speed: Shift or whatever on a low-end Android device does not "fragmentation" make. There were plenty of computers that were fully "IBM compatible" in the early 90s that couldn't run DOOM.
It's the EXACT same situation. Apple releases one line of products that is locked down to their OS, expensive, and internally inferior to the like-priced competition. The competition - be it Microsoft then or Google now - licenses their operating system for use on a slew of competing products covering all ranges of performance, at a lower price.
Mark my words: in a decade, most people won't even remember Apple was ever a major player in the smartphone market. They'll be forced to re-image themselves as a "boutique" product for idiots who value form over function and cost-effectiveness, just like their PCs.
Or to use your example: how many people got Macs for Christmas in the 80s? How about now?
iPhone and Windows 7 both have a GPU as standard. Android is the only platform where the GPU is optional. Google created the fragmentation by leaving the minimum hardware requirements lower. On the upside, some Android devices will be cheaper. On the downside the OS is crappier because it has to cater for lower spec. devices.
IMHO, sarcasm is insightful, rather than funny.
Furthermore, moderation can be used to augment the message, instead of simply commenting on the quality of the message. For example, a post saying "I just shat myself" could be modded informative. This might explain why I am often moderated insightful when meaning to be funny, and vice versa.
Escher was the first MC and Giger invented the HR department.
The USA.
Never heard of it. Is that one of those little countries that popped up when the Soviet Union fell apart?
Jesus was all right but his disciples were thick and ordinary. -John Lennon
There is absolutely a hardware reference for Android. It requires a CPU based on the ARM11 or newer architecture, at least 256MB of RAM, at least so much (not sure on exact numbers, "enough to fit Android + system Apps") flash storage, and a touchscreen. That's the same as saying "IBM compatible,"
No, it's not.
which really just meant "80286 or better CPU, enough RAM to run DOS, a screen, and a keyboard."
No it wasn't. IBM compatible defines a lot of things, including BIOS and various busses.
With things like a smartphones, there are far too many variables for it to be like "IBM compatible".
The inability to run Need for Speed: Shift or whatever on a low-end Android device does not "fragmentation" make. There were plenty of computers that were fully "IBM compatible" in the early 90s that couldn't run DOOM.
And if your CPU wasn't a 386, or a 486 DX2 50 (for optimum performance), you knew you couldn't run DOOM. With a smartphone, the user doesn't know which chips will run an app well or not. There's no proper frame of reference.
So, yeah, simply not being able to run some game on slower phones "does not 'fragmentation' make", that's just the tip of the iceberg.
It's the EXACT same situation. Apple releases one line of products that is locked down to their OS, expensive, and internally inferior to the like-priced competition.
That's a load of bullshit. When I looked into this, I was shocked that many Android phones cost more than the iPhone, yet have lesser features, including having abysmally small flash memory.
Mark my words: in a decade, most people won't even remember Apple was ever a major player in the smartphone market.
HAHAHA. You should have started your post off with this. It's a real gem.
They'll be forced to re-image themselves as a "boutique" product for idiots who value form over function and cost-effectiveness, just like their PCs.
No, only blindered geeks image Apple as a "boutique" product maker. Form is inextricably tied to function. Macs are very cost-effective. They just don't have a low end (which consumers would like) and they don't have DIY kits (like the geeks like). But when you go into the price range where Macs are, you tend to find nothing but inferior PCs at usually superior prices.
Or to use your example: how many people got Macs for Christmas in the 80s? How about now?
Significantly more got them now than in the '80s. I'm not sure what your point is.
It's also very difficult to know which device to even upgrade to! It's not like PCs where you can say, "well, this game needs a 5770 and a Core i5 quad" and you can just spec out an upgrade to give you that. It's more like, "this app is slow. which phone can run it better?", which will leave most consumers confounded, and they will be forced to opt for the "find some other preoccupation" route, which is going to really sour their experience.
Do you think consumers in the 80s were any smarter than the modern day counterparts? How do you think consumers knew which IBM clone had what specs to run which game? They went to a store and asked some guy there "will this run such and such?" and found a computer that fits their needs. The same thing can happen with phones. The consumer walks into the store for their upgrade and says "I have such and such slow phone. I need a phone that is faster." and the clerk, just like in the 80s, points to the various phones and says which ones are faster or not.
It's the exact same situation.
Buy a fucking phone... then subscribe to whatever plan that fulfills your mobile communication needs... and not more then that...
Most of us would love to do this. It's just not available in the US on most major Carriers. Which fucking sucks.
T-mobile prepaid isn't bad. You pay 10c a minute for phone calls and $1.50 per day for data. If you only need to use data every few days then it works out quite a bit cheaper.
The language itself has 0 to do with its speed.
Depends, I mean for some algorithms lacking unsigned types in java the language is a hindrance, sure the hardware can do unsigned bytes but without the language exposing it what's the point.
If only Android could be rewritten in Javascript..
Better throw in some XML for good measure...
Good idea! I propose we call this monstrosity WebOS.
The stack ranking system is nearly a carbon copy of Microsoft's
The promotion systems are nothing like each other between those two companies (I've worked at both). The (optional) peer stack ranking at Google is a small part of the peer-driven review system. Microsoft (at least when I was there) had the traditional manager-driven reviews and ranking. It is true that those very different sources of data led to an overall ranking at both companies, but I don't see how else you'd apply a threshold consistently. Unlike most tech companies, Google has no fixed maximum of people that can be promoted or given raises, just guidelines on what it takes to meet the threshold.
The result is inevitable degradation of the engineering culture.
Google has a near-weekly meeting where you can question anyone up to the CEO, and a culture that says that just about any topical question is fair game. This is an important check on culture degradation, and I've certainly not seen anything like it at another company with over a thousand employees.
Google certainly has its share of issues with bad hires that don't get along well, or projects and offices that get overrun with people who bring traditional IT-company culture with them from their former workplaces. Perhaps you were stuck in such a situation and I apologize. However the difference between Google and Microsoft (for me at least) is still night and day.
Ahem...
Add to that this... Most SoC's run a fairly narrow and slow memory bus. Also, GPU's tend to be WAY slower than CPUs...
Fancy racing a 4 * 150Mhz pipe GPU against a 1 Ghz, superscalar CPU with 64/128 bit SIMD extensions?
Who will win?
Answer... the memory bus. You can TRY and get the CPU and GPU to work together but all that will happen is that the memory bus will get swamped and everything slows down.
GPUs can render polys with straight edges. UIs frequently want curved, rounded objects with complex gradients and complex blend modes not supported by GPUs.
TBH the article is nonsense. Android composites using OpenGL. Individual applications render with SKIA for 2D. The SKIA API is deliberately immediate mode to reduce latency (GPU's do not multitask and have rubbish MMUs). All applications are back buffered so they cache bitmaps pretty well. Bitmap copying is minimal.
Maybe a scene graph would help - but you'd increase latency greatly and (if GPU accelerated) you'd make the GPU task switch - not quick on many (most) GPUs.
Also - Poly throughput isn't the problem - fill rate is... (see Memory Bus above).
Burnttoys.
Time flies like an arrow. Fruit flies like a banana.
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 [..]
OpenGL ES 2 == OpenGL ES 2. Just write one compositor that uses it, and one that doesn't. Problem solved. The iPhone 3G and earlier didn't have OpenGL ES 2 either, but that didn't stop Apple from utilizing it for the UX on the 3GS and upwards.
No, but then vendors have to compile for and test on 14 different platforms and 3 different kernels. There are definitely diminishing returns there, and the 90% of the configurations with 10% of the users will be left with untested and potentially buggy. "Normal people" want Android to be Android and choose a device based on the sleekness of its ads and cuteness of its logo, rather than based on chipset model numbers.
We'll probably end up in a Wintel type scenario, but it's a noble effort even if it's doomed.
Do it all in html5/js.
Liberty freedom are no1, not dicks in suits.
Which is it dude, LG and Samsung?
LG have some good low end capable devices with crap screens (eg GT540)
Theres no such thing as a Samsung LG Optimus, its only LG Optimus by LG ok, just LG.
Liberty freedom are no1, not dicks in suits.
It's also very difficult to know which device to even upgrade to! It's not like PCs where you can say, "well, this game needs a 5770 and a Core i5 quad" and you can just spec out an upgrade to give you that. It's more like, "this app is slow. which phone can run it better?", which will leave most consumers confounded, and they will be forced to opt for the "find some other preoccupation" route, which is going to really sour their experience.
Do you think consumers in the 80s were any smarter than the modern day counterparts?
Absolutely. Specifically, consumers who bought computers in the '80s and early '90s. Because computers were still relatively rare back then, so it was a self-selected geek subset that bought computers.
How do you think consumers knew which IBM clone had what specs to run which game? They went to a store and asked some guy there "will this run such and such?" and found a computer that fits their needs.
They looked at the box. Back then, everyone knew what CPU they had, which was the only thing that really mattered for Doom.
The same thing can happen with phones. The consumer walks into the store for their upgrade and says "I have such and such slow phone. I need a phone that is faster." and the clerk, just like in the 80s, points to the various phones and says which ones are faster or not.
It's the exact same situation.
It's not. Because it's not simply a matter of a choosing a phone with a faster CPU. Now it's a many-dimensional feature matrix. It's far, far more complex. Especially given how hidden the internal specs are, and the fact that things like responsiveness of the touch display and upgradeability are not even discernible from the specs, and other things are orthogonal to performance, like keyboard style, size, camera, etc.
And it's not like people are going to walk into the store knowing ahead of time which apps they will end up wanting to run, and it's not feasible to upgrade your phone just to play Angry Birds today, then again for Epic Citadel tomorrow.
Also, back then, the computer salesman could state objectively that a given PC was superior or not than some other. This is almost still true today, except that it's not always clear between things like AMD or Intel, ATI vs Nvidia, and even whether quad core but slower clock is better than faster clock, but dual core, because of variability in usage patterns.
Anyway, the point being, the consumer has no way to know which phone is the right one to pick.
The silly thing here is Android proponents acting like fragmentation isn't an issue. It undeniably is. With the iPhone, the matrix is essentially either current or previous gen, different flash storage capacities, and sometimes color. With the iPhone, you know that the current gen will run *all* apps on the App Store at the best performance.
This is an inevitable side-effect of Android's key strength. You can't have the one without the other. And for the iPhone, this is why the single source is such a key benefit.
If you want choice, you *must* give up usability and overall user experience. But you do get choice. If you favor usability and user experience, you give up choice. It's no surprise that a lot of geeks are fine with the downsides of choice, and prefer the benefits choice has to offer. And it's no surprise that the average consumer would rather give up choice for a better experience.
What is surprising, however, is the legions of geeks who can't seem to grasp this.
I have a Galaxy S and the browser is the stock Android one. I even did an MD5 comparison of the binary (my phone is rooted) with a vanilla ROM to confirm. If there is any optimisation it must be at the driver level.
The biggest improvement to performance I have ever seen for Android is the One Click Lag Fix you can download from the Market (needs root). It creates a new EXT2 formatted disk image and copies all your apps and their core data to it. Apparently the next revision of Android will have a better filesystem anyway but OCLF alone makes things much snappier on Froyo. That suggests that the bottleneck isn't the GPU or CPU most of the time, it is the speed of flash memory and by extension the amount of available RAM (since more RAM = more caching and less flushing.)
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
The stack ranking system is nearly a carbon copy of Microsoft's
The promotion systems are nothing like each other between those two companies (I've worked at both). The (optional) peer stack ranking at Google is a small part of the peer-driven review system. Microsoft (at least when I was there) had the traditional manager-driven reviews and ranking. It is true that those very different sources of data led to an overall ranking at both companies, but I don't see how else you'd apply a threshold consistently.
Google talks a great peer review system but does not walk a great peer review system. Peer review, whether positive and negative, can be and is routinely ignored by managers. There are no checks and balances, ask around.
Unlike most tech companies, Google has no fixed maximum of people that can be promoted or given raises, just guidelines on what it takes to meet the threshold.
And "exceeds" are only given out to friends, and except for the lowest ranked employees, promotions likewise. There are exceptions of course, but the rule is pretty much the same as Microsoft, just not quite as far advanced down the GE path.
The result is inevitable degradation of the engineering culture.
Google has a near-weekly meeting where you can question anyone up to the CEO, and a culture that says that just about any topical question is fair game. This is an important check on culture degradation, and I've certainly not seen anything like it at another company with over a thousand employees.
This is nice its true, but you also better take care to softball your questions. "Larry I heard you can do one armed pushups, can I see you do it?" Avoid "is it true you expect new hires to accept below market compensation for the privilege of working at the world's most awesome company?"
Google certainly has its share of issues with bad hires that don't get along well, or projects and offices that get overrun with people who bring traditional IT-company culture with them from their former workplaces. Perhaps you were stuck in such a situation and I apologize. However the difference between Google and Microsoft (for me at least) is still night and day.
It would not surprise me if your Microsoft experience was way worse than your Google experience. I was in fact in a satellite office with serious leadership issues, however I spent plenty of time in MTV as well and I observed the same issues in many situations. Just not as bad as Microsoft, but in the absence of concert remedial action, well on the way to being a carbon copy. I did in fact witness the degradation of the engineering process over the years I was there. And getting back to the topic at hand, you can see the result in the many little stupid issues in the shipped software, that never get fixed year after year. For example, when my phone knows exactly where I am and I type in the name of a restaurant, why am I shown a map of China? When I get a upgrade completion notification on the main screen, why must I start the application to dismiss it? Why can't I write an application that bypasses Java completely, when everybody knows Java is an intellectual property minefield?
Have you got your LWN subscription yet?
If I had mod points ... but its so true. Linux supports more hardware than Windows ever has, and does it very well. Too bad about those old myths.
- Michael T. Babcock (Yes, I blog)
I have an old Tmoby pulse (huawei 8230) running Android 2.2. I can confirm that the battery usage is very much affected by Screen/GPS/WIFI and 3G connections in that order. The idea that the UI effects is the power sucker is: 1. A crock. 2. If it was true, avoidable by disabling window animations in settings 3. For power consumption, brightness, time out of screen saver, intelligence about wireless devices come so much higher up the list as to make this whole topic so irrelevant it isn't rel. P.S. Other things I like on this thread are people suggesting, what about people on older Android where performance is poor. Good argument, my Tmoby pulse has been on Android 1.6, 2.1 and 2.2 each upgrade adds more flair and makes the battery/performance better. How is this a failing for software development? A failing is when you release a new version of your OS and hardware a couple of years old runs like a total dog and is less efficient (looks at iOS and Apple hmmm). The old fashioned bloat and replace cycle of pay for software and tied in Hardware companies...
Well, I do not observe these on a Nexus One running MIUI or a G Tablet running Vegan ROM.
But I do agree that there is a theoretical issue associated with these. In fact, it was a practical issue on first gen devices - I used to observe these on my old G1 due to constrained memory and a slow CPU. You'd see the things stutter when the GC kicked in.
And I am not saying there isn't room to fix up or clean some of the Android UI stuff - accelerated compositing is a good idea, better control of the garbage collection stuff, another one. That wasn't my point.
Just saying that Java/Dalvik works well on second gen Android devices, and there is nothing fundamentally wrong with Java on a mobile device. The people who think otherwise are generally basing their opinion on experiences with first gen or similarly constrained devices (single core, 500MHz, no JIT, etc.).
Well, let's be honest, if doing something in a particular way hurts you: stop doing it!
There is nothing in Java that says that you need to constantly throw out object and create new ones. These days these are object factories and what not out there that you can use to optimize these things.
News about the Kettle Open Source project: on my blog
The idea that the UI effects is the power sucker is...
Nowhere stated nor implied in my post. Are you sure you replied to the correct post? Mine was mostly about poorly optimized applications being a huge battery drain. It has nothing to do with window animations.
Other things I like on this thread are people suggesting, what about people on older Android where performance is poor. Good argument, my Tmoby pulse has been on Android 1.6, 2.1 and 2.2 each upgrade adds more flair and makes the battery/performance better.
This was something I mentioned. Older versions of Android perform more poorly with regard to battery life, but because of the way Android is deployed by vendors, many phones are not updated in a timely fashion (some are never updated). This exacerbated the battery performance issues that are one of Android's biggest weaknesses.
Indeed your achieles heel comes in the shape of poor 3rd party apps, though this whole thread is about the need to render the UI via GPU for the sake of power.
Please name and shame these poorly optimised android apps (that presumably don't exist evenly across mobile platforms?), or accept the fact that the hardware burns through so much power than virtually any trivial (and without the hardware mentioned mobile apps generally are trivial) applications power use is irrelevant.
If you want choice, you *must* give up usability and overall user experience. But you do get choice. If you favor usability and user experience, you give up choice. It's no surprise that a lot of geeks are fine with the downsides of choice, and prefer the benefits choice has to offer. And it's no surprise that the average consumer would rather give up choice for a better experience.
You're absolutely right but there is some middle ground as well, which is the strategy Microsoft has taken with WP7. They have determined a range of hardware to tune the user experience. Sure it limits choice a bit but you don't end up with devices that struggle to run the OS & apps and destroy the user experience and platform reputation.
Additionally developers know what the minimum spec is and can work with that to ensure the performance of their software is consistent across devices.
I think it's great that we have these 3 different platforms addressing effectively the same market with 3 different strategies all with different up- and downsides. It means you generally have a good option no matter which demographic you fall into.
Indeed your achieles[sic] heel comes in the shape of poor 3rd party apps, though this whole thread is about the need to render the UI via GPU for the sake of power.
That's only one of the topics he brings up with regard to performance in his article, although it is one focused upon heavily in the discussion. Referring to Android phones as having "only average" battery performance when compared to an iPhone, however, is being politic and the AC I was replying to was making some rather spurious claims in that regard.
Please name and shame these poorly optimised android apps (that presumably don't exist evenly across mobile platforms?)
I don't have the resources to do large scale testing, nor do I even have an iPhone and Android of my own, just access to them for testing at work. Anecdotally: eBuddy, Qik, ESPN sports center, fring, imovicha. Note several are IM clients that some reason ignore the push APIs and Google has no way to force them to use the push features.
But as to whether or not they exist cross platform evenly, well no I strongly suspect they don't for a variety of reasons. Apps on the iPhone are limited in dev tools and in access to system resources much more so than Android apps. This is annoying as a developer and even as a power user, but it also means apps can't just start sending pings to a server on a regular interval, but instead are required to use push services and are required to break out only specific types of background threads when running in the background. They can't constantly query the GPS if they aren't in the foreground.
...or accept the fact that the hardware burns through so much power than virtually any trivial (and without the hardware mentioned mobile apps generally are trivial) applications power use is irrelevant.
Perhaps you're laboring under a misunderstanding. Apps are software that makes the hardware do things. ALL battery usage is a combination of software AND hardware. It's a matter of what hardware and how often it is used by an app. Does it use the built in push notification service like a good app or does it waste battery power constantly running a thread in the background and constantly sending unneeded data? (Note I keep coming back to the network usage model, because it is a big differentiator with real, measurable battery ramifications.) There are several other, similar API issues, especially allowed multitasking modes. Remember when Apple came out with a castrated version of multitasking and we all scoffed, well if you read the Google engineering Android blogs, they sure wish they'd come up with the same thing because multitasking as implemented is killing battery as much as any other factor. (Read Larry Page's comments on it if you want an authoritative view from a Google founder.)
That's only one of the topics he brings up with regard to performance in his article, although it is one focused upon heavily in the discussion. Referring to Android phones as having "only average" battery performance when compared to an iPhone, however, is being politic[sic] and the AC I was replying to was making some rather spurious claims in that regard.
So your opinion is that he meant to say "much worse", either way I'm an evidence man. If either the Originator or you have something specific feel free to post.
I don't have the resources to do large scale testing, nor do I even have an iPhone and Android of my own, just access to them for testing at work. Anecdotally: eBuddy, Qik, ESPN sports center, fring, imovicha. Note several are IM clients that some reason ignore the push APIs and Google has no way to force them to use the push features.
Thanks for your suggestions of the offenders, albeit with your proviso that you haven't tested your theories. I'd also be interested in how popular the apps you have issue with are with the rank and file Android users you suggest are at such risk.
But as to whether or not they exist cross platform evenly, well no I strongly suspect they don't for a variety of reasons. Apps on the iPhone are limited in dev tools and in access to system resources much more so than Android apps. This is annoying as a developer and even as a power user, but it also means apps can't just start sending pings to a server on a regular interval, but instead are required to use push services and are required to break out only specific types of background threads when running in the background. They can't constantly query the GPS if they aren't in the foreground.
I agree the development environments and eco systems are very different, as an Android user I've pointed out what I believe is a major advantage, in that the OS has become tangibly more efficient on older hardware, a trait I have also observed in Linux but never in a proprietary operating system, especially one where the developer gains direct profit from each new hardware sale. As to the idea that apps made for such an open eco system are likely to be lower quality than proprietary ones. This is not a new suggestion but one I've yet to see great evidence for. For example FLOSS often has several active projects with similar goals, whilst some may be poorer/weaker others are often very high quality, that is called competition. It may be possible for Android users to download all kinds of rubbish should it exist, the market is after all relatively free/open, it doesn't mean we will or that we do.
Perhaps you're laboring under a misunderstanding. Apps are software that makes the hardware do things. ALL battery usage is a combination of software AND hardware. It's a matter of what hardware and how often it is used by an app. Does it use the built in push notification service like a good app or does it waste battery power constantly running a thread in the background and constantly sending unneeded data? (Note I keep coming back to the network usage model, because it is a big differentiator with real, measurable battery ramifications.)
Perhaps you are labouring under a misconception. All battery usage comes from the flow of current through hardware, software is generally any information, this may be said to be stored on flash (or other non volatile) memory, However information (like an idea) consumes no current. This is why software is generally protected by intellectual property laws, not property laws. Now it's OK to say that hardware usage may be affected by the design of software and you are welcome to argue that on average that popular software is more likely to be flawed on the Android ecosystem than the iPhones. If you have good evidence of this please do show that. My also anecdotal experience is that a clean Android 2.2 is a good deal better than a clean 2.1 or 1.6 at manag
That suggests that the bottleneck isn't the GPU or CPU most of the time, it is the speed of flash memory and by extension the amount of available RAM (since more RAM = more caching and less flushing.)
Unfortunately, that doesn't really make any sense since the Galaxy S series has similar(probably even same) flash to the iPad and Samsung Windows Phone 7 units, but at least the iPad doesn't suffer from the same lag.
(I have an iPad and a Nexus S.)