Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Care and Feeding of the Android GPU

CmdrTaco posted more than 3 years ago | from the eet-mor-hooman dept.

Google 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."

Sorry! There are no comments related to the filter you selected.

I've complained about this more times than i care. (2, Insightful)

Anonymous Coward | more than 3 years ago | (#34756846)

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.

Re:I've complained about this more times than i ca (1)

teh31337one (1590023) | more than 3 years ago | (#34757674)

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.

Doesn't Optimizing for GPU Exacerbate Fragmenting? (2, Insightful)

eldavojohn (898314) | more than 3 years ago | (#34756850)

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 (0)

MobileTatsu-NJG (946591) | more than 3 years ago | (#34756910)

Doesn't optimization for particular hardware exacerbate their issues with fragmentation?

Ssshhhh, fragmentation is a myth!

Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (0)

morgan_greywolf (835522) | more than 3 years ago | (#34757298)

Show me an issue of fragmentation. 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.

Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (1, Informative)

MobileTatsu-NJG (946591) | more than 3 years ago | (#34757432)

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.

Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (1)

bonch (38532) | more than 3 years ago | (#34757646)

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.

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.

Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (3, Insightful)

Desler (1608317) | more than 3 years ago | (#34756914)

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:Doesn't Optimizing for GPU Exacerbate Fragmenti (0)

Anonymous Coward | more than 3 years ago | (#34756934)

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.

Yeah and now you're talking about a massively different user experience on different devices ... that's really annoying to application developers.

Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (1)

Desler (1608317) | more than 3 years ago | (#34756962)

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 [appleinsider.com] ?

Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (4, Insightful)

TopSpin (753) | more than 3 years ago | (#34757634)

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.

Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (1)

MobileTatsu-NJG (946591) | more than 3 years ago | (#34756982)

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?

Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (1)

Desler (1608317) | more than 3 years ago | (#34757052)

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.

Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (4, Interesting)

0100010001010011 (652467) | more than 3 years ago | (#34757270)

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

Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (4, Insightful)

MobileTatsu-NJG (946591) | more than 3 years ago | (#34757384)

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 (3)

RightSaidFred99 (874576) | more than 3 years ago | (#34756916)

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.

Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (4, Insightful)

iluvcapra (782887) | more than 3 years ago | (#34756978)

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.

Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (5, Insightful)

TheRaven64 (641858) | more than 3 years ago | (#34757392)

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).

Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (0)

Anonymous Coward | more than 3 years ago | (#34757062)

Going along this line of reasoning is simliar to what microsoft does, once the basic foundation is mammoth size and wanting,
complain about everything else all the while expanding the mammoth to a full blown Sauropod.

Dual core + higher powered procs on a phone = bad idea, you probably need a personalized body electricty generator to keep it juiced.

I think at some point someone has to decide to support a few GPUs or the companies themselves provide their certified drivers for android.
Even now with the latest android phone the interface is still choppy compared to the silky smoothness of the iphone you can take it to a dual core but have feeling its going to be the same.

Its like comparing mesa to running compiz under proper ati/nvidia drivers everything just looks in place.

-S

Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (0)

Anonymous Coward | more than 3 years ago | (#34757320)

Yes, a graphics API or HAL with drivers for each GPU is the only real way to achieve parity with other platforms. It makes sense to do that if Android wants to get accelerated graphics (which it should).

Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (1)

whiteboy86 (1930018) | more than 3 years ago | (#34757098)

Smartphone and no GPU? That is not a smartphone in 2011.

Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (4, Insightful)

bhcompy (1877290) | more than 3 years ago | (#34757132)

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.

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 (1)

bonch (38532) | more than 3 years ago | (#34757694)

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.

Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (2)

alvinrod (889928) | more than 3 years ago | (#34757136)

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.

Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (0)

Anonymous Coward | more than 3 years ago | (#34757200)

The article gets into how Silverlight uses the GPU to accelerate certain operations as he is referring too in his post.

I assume using "just" is a reference to the fact that it's not even 3 months old in terms of being on the open market.

Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (4, Insightful)

TeknoHog (164938) | more than 3 years ago | (#34757216)

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.

Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (1)

billcopc (196330) | more than 3 years ago | (#34757506)

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.

Lead to... as in the future? (1)

Servaas (1050156) | more than 3 years ago | (#34756862)

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...

Re:Lead to... as in the future? (0)

bonch (38532) | more than 3 years ago | (#34757196)

"Supporting a wide range of products" is leading to animation pauses and jerky scrolling. That's a bad thing for a touchscreen smartphone.

Re:Lead to... as in the future? (1)

ByOhTek (1181381) | more than 3 years ago | (#34757304)

There's this thing called 'modular programming'. You program things in coherent chunks. For example, you could program a good bit of the lower-level UI level stuff in a chunk (window/panel handling, for example) to handle any system. Now later, you could say "Wait, we could make this faster with Accelerated Hardware X) and then make a second module, that can be accessed in the same way, but uses Accelerated Hardware X. Now, at load time (or install time, or configuration time), it could spend a half dozen cycles to determine if Hardware X is available, and run that module or the default based one the result.

No support is lost, but some platforms will perform better.

java's architecture is broken by design (0)

MichaelKristopeit355 (1968164) | more than 3 years ago | (#34756866)

if the java subsystem requires garbage collection in a separate process, then garbage collection will always relatively block the system.

Re:java's architecture is broken by design (0)

Anonymous Coward | more than 3 years ago | (#34757144)

why do you post at zero? why do you pretend to use your real name?

you're completely pathetic, feeb.

Re:java's architecture is broken by design (0)

MichaelKristopeit355 (1968164) | more than 3 years ago | (#34757212)

as you have conceded my use of my real name, you're an ignorant hypocrite.

i post at zero because marketeers have attempted to silence me for pointing out such obvious logical failures in their products.

you're an idiot.

Re:java's architecture is broken by design (0)

Anonymous Coward | more than 3 years ago | (#34757738)

why can't you understand the meaning of the word pretend?

cower behind your chosen pseudonym.

Failure of lazy open sores developers (-1)

Anonymous Coward | more than 3 years ago | (#34756870)

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 pause

Well duh. It's hard to do it the right way so open sores developers take the shitty route to shortcut the problem which doesn't really solve it in the end. This is why a system backed by a real software company, not an ad firm, is what you should be running on your phone.

Oh and in case you didn't know or forgot, CmdrTaco has a micropenis.

Re:Failure of lazy open sores developers (1)

the linux geek (799780) | more than 3 years ago | (#34757012)

Surprisingly perceptive for a troll......

Java, the original sin (0, Redundant)

Scareduck (177470) | more than 3 years ago | (#34756874)

Additionally, Android runs Java bytecode

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.

Re:Java, the original sin (2)

teknopurge (199509) | more than 3 years ago | (#34756954)

Because it's not bad at all. A shoddy workman blames his tools.

Re:Java, the original sin (1, Insightful)

Desler (1608317) | more than 3 years ago | (#34756976)

A shoddy workman blames his tools.

And a great workman knows that certain tools are shitty and worthless.

... and the expert gets to chose his own tools. (1)

eddy (18759) | more than 3 years ago | (#34756988)

That's great for those who want it, but how about those of us who'd rather bang closer to the metal?

Re:... and the expert gets to chose his own tools. (1)

Desler (1608317) | more than 3 years ago | (#34757064)

Then don't bother with Android. Even if you use the NDK you are still having your program sandboxed in the VM and you get no real speed benefits.

Re:... and the expert gets to chose his own tools. (1)

Anonymous Coward | more than 3 years ago | (#34757194)

Then don't bother with Android. Even if you use the NDK you are still having your program sandboxed in the VM and you get no real speed benefits.

Entirely incorrect in the facts, though perhaps a decent conclusion.

The davlik VM does not provide any sandboxing, nor does native code run within it.

Instead, applications are sandboxed by the linux kernel, each running as it's own userid.

This does tend to prevent low-level access to the hardware from native code which ordinarily cannot gain the necessary linux-level permissions to the device files, etc. And the provided high-level APIs for talking to services which do have low-level access tend to be java only, requiring native code to go back up through jni before it can do much.

Re:... and the expert gets to chose his own tools. (0)

Anonymous Coward | more than 3 years ago | (#34757076)

Android NDK

Re:... and the expert gets to chose his own tools. (1)

Aladrin (926209) | more than 3 years ago | (#34757130)

Then fragmentation really does become a problem because the processor is not guaranteed to be any particular model. You'd have to manually compile for each one.

That's why the JVM (or .NET CLR) is so nice. You can compile once and have it run on all devices.

Re:... and the expert gets to chose his own tools. (1)

h4rr4r (612664) | more than 3 years ago | (#34757156)

.NET on all devices? Are you mad?

No matter what MS likes to claim .NET is not portable in any meaningful way. The day I see MS made virtual machines for linux and mac is the day .NET becomes portable.

Re:Java, the original sin (1)

Lunix Nutcase (1092239) | more than 3 years ago | (#34757004)

A shoddy workman blames his tools.

Unless the tool is the thing that is shoddy.

Re:Java, the original sin (0)

Anonymous Coward | more than 3 years ago | (#34757126)

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.

Re:Java, the original sin (1)

Desler (1608317) | more than 3 years ago | (#34757206)

And in this case the particular programming language, Java, is shoddy.

Re:Java, the original sin (1)

bennomatic (691188) | more than 3 years ago | (#34757208)

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.

Re:Java, the original sin (2)

Carewolf (581105) | more than 3 years ago | (#34757650)

Of course, the OP might be suggesting that Java on mobile devices might be like using a sledgehammer for hanging a picture frame.

At least a sledgehammer is an actual hammer. Using Java on a mobile devices is more like using a whale to hammer in screws.

Re:Java, the original sin (1)

davidbrit2 (775091) | more than 3 years ago | (#34757040)

And an idiot workman pounds nails with a pile driver.

Re:Java, the original sin (0)

Anonymous Coward | more than 3 years ago | (#34757308)

Are you kidding? We now have Ghz processors in handhelds and my old 33Mhz Palm is still more responsive when editing a text document. Android is ridiculously inefficient.

Re:Java, the original sin (1)

Fnkmaster (89084) | more than 3 years ago | (#34757340)

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.

Re:Java, the original sin (1)

dgatwood (11270) | more than 3 years ago | (#34757502)

Because it's not bad at all.

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.

A shoddy workman blames his tools.

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.

Re:Java, the original sin (0)

Anonymous Coward | more than 3 years ago | (#34756990)

Additionally, Android runs Java bytecode

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.

Android does not run Java bytecode. http://en.wikipedia.org/wiki/Dalvik_%28software%29

Re:Java, the original sin (3, Informative)

alen (225700) | more than 3 years ago | (#34757014)

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.

Re:Java, the original sin (1)

alvinrod (889928) | more than 3 years ago | (#34757252)

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.

Re:Java, the original sin (1)

whiteboy86 (1930018) | more than 3 years ago | (#34757020)

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".

Re:Java, the original sin (1)

The End Of Days (1243248) | more than 3 years ago | (#34757180)

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.

Re:Java, the original sin (0)

Anonymous Coward | more than 3 years ago | (#34757038)

Actually, Android does not run Java bytecode at all. It runs Dalvik [wikipedia.org] bytecode.

Re:Java, the original sin (2)

tixxit (1107127) | more than 3 years ago | (#34757524)

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?

Re:Java, the original sin (1)

Mongoose Disciple (722373) | more than 3 years ago | (#34757626)

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.

Waiting for better hardware == Java applet death (0)

vlueboy (1799360) | more than 3 years ago | (#34756886)

Waiting for hardware to improve in light of today's slow phone makers just puts things in their hands. Users are lots faster at switching back from an annoyingly slow phone than the company making it is to silently upgrade that product line with faster hardware.
Outside of academia, JS and Flash became alternatives over the hardware hungry Java Applet segment. Google must be the party best-aware of how fragmentation and lack of telco UPDATES put a hamper on the Android name. That they are stating they want the fragmented market to uniformly float up to levels where the worst phones are not unusably slow just shows that they are not evaluating the markets right. Netbooks have been out ~5 years, yet hardware never got past 1GB of RAM and speeds never got near the raw power to watch Youtube that low-end laptops have had for years.

Re:Waiting for better hardware == Java applet deat (1)

h4rr4r (612664) | more than 3 years ago | (#34756952)

I watch youtube on my netbook just fine. It has 2GB of ram and an SSD. WTF are you on about?

Re:Waiting for better hardware == Java applet deat (1)

Veldcath (591080) | more than 3 years ago | (#34756992)

My netbook may only have 1 GB of RAM, but I watch Youtube, Hulu and Netflix on it in standard definition, no real troubles?

Re:Waiting for better hardware == Java applet deat (0)

Anonymous Coward | more than 3 years ago | (#34757056)

I agree with you that the product cycle is longer in the mobile phone business.
If netbooks are still limited it's because intel has strict restrictions on devices using the atom. In order not to cannibalize its own market share on other markets.
But in the end, the phone maker policy of not upgrading embarked software benefits this approach because software will always have hardware synchronized with. I agrre it's a misery for the user, still hardcore projects enable power users to keep pace. And not that much people needs a phone optimized for "fast latest 3D games". Those people and the crazy geeks will always want to have bleeding edge and will buy. The other people like me will use their phone and its handy apps as long as it is working. By the way, that's how we should behave to save the planet.

Re:Waiting for better hardware == Java applet deat (1)

whiteboy86 (1930018) | more than 3 years ago | (#34757066)

Waiting for better hardware

That was the very purpose of inefficient Java.
(to sell Sun's 'better' hardware)

Possible Fix (0)

Anonymous Coward | more than 3 years ago | (#34756946)

One possible way to fix this, if it is indeed a problem, is to do exactly what Apple is doing. This short writeup describes it well (read the section titled "OpenCL Compiler"):

http://developer.apple.com/library/mac/#documentation/Performance/Conceptual/OpenCL_MacProgGuide/OpenCLontheMacPlatform/OpenCLontheMacPlatform.html

Each graphics card is running a low level virtual machine (LLVM, also the name of the compiler used, noteable for this ability) which emits optimized instructions on the target card. A different backend may be required for each graphics card, but each generation is not so different than the last.

What we need... (0)

digitaldc (879047) | more than 3 years ago | (#34756958)

...are more efficient batteries. Google could save a lot of headache by putting some of its billions in to rechargeable battery research.

Re:What we need... (0)

Anonymous Coward | more than 3 years ago | (#34757044)

Power consumption can be controlled. Having video hardware do work is cheaper in energy than a CPU doing it. This has been known for a very long time. Google are being lazy. Their rendering can support both. We've had this in openGL for fscking years. It's nothing new.

Re:What we need... (0)

Anonymous Coward | more than 3 years ago | (#34757096)

Only an advantage if you are the only one with access to the better batteries. With the current Android ecosystem, that is not going to happen.

sounds like a job for JIT (2)

larry bagina (561269) | more than 3 years ago | (#34757046)

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.

Re:sounds like a job for JIT (2)

h4rr4r (612664) | more than 3 years ago | (#34757100)

Which means you now have to support how many cards? Are the vendors going to provide drivers that can even go into the android project?

Re:sounds like a job for JIT (2)

Entrope (68843) | more than 3 years ago | (#34757296)

Cell phones are not known for having many kinds of graphic cards available. Heck, they're not even known for using many kinds of discrete graphics chips. I will even go so far as to say that they draw from a rather narrow set of embedded graphics cores.

PowerVR is pretty much the market leader, ARM is playing catch-up with Mali, and then you get the long tail. GPU core and SoC vendors know how to work together to deliver usable libraries for chip buyers -- witness the OpenGL ES acceleration that is available for the Texas Instruments OMAP series of processors (BeagleBoard, etc.).

It should not be that hard for Google to get decent acceleration that works on a large fraction of modern phones, while falling back to software rendering for older phones.

Re:sounds like a job for JIT (1)

h4rr4r (612664) | more than 3 years ago | (#34757422)

Usable for chip buyers, which means probably not generally available. Thus meaning as google is not a chip buyer what are the odds they will get gpl, bsd or apache licensed code?

And yet, somehow, it's WORKING!? (2, Interesting)

mcrbids (148650) | more than 3 years ago | (#34757210)

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.

Re:And yet, somehow, it's WORKING!? (0)

h4rr4r (612664) | more than 3 years ago | (#34757254)

Do you work for them?

This reads like an ad, you could just be really happy about them I guess.

Re:And yet, somehow, it's WORKING!? (0)

Anonymous Coward | more than 3 years ago | (#34757284)

I couldn't agree with you more. The Optimus is a wonderful phone and you can get them for nearly free now (free as in 2-year contract with a major carrier in the US)

Re:And yet, somehow, it's WORKING!? (0)

Anonymous Coward | more than 3 years ago | (#34757328)

I'm in a similar situation, and this afternoon I'm going to go buy my wife the Samsung Intercept for Virgin Mobile. Phone is $250, and the coverage around us is good (she already has a VM flip phone). But best of all is unlimited data/text/messaging and 300 minutes for $25/month, and no contract. I can't see paying AT&T prices, even though the iphone is a bit nicer.

Re:And yet, somehow, it's WORKING!? (0)

Anonymous Coward | more than 3 years ago | (#34757360)

a good, full day of battery life.

That doesn't sound like an advantage. I get a week of battery life out of my mobile phone and it's about four years old. I would have thought that battery life was increasing in newer phones, not decreasing.

Re:And yet, somehow, it's WORKING!? (1)

Spectre (1685) | more than 3 years ago | (#34757590)

Battery life for "smartphones" is pretty much stuck at "the battery goes flat after 16 hours" if you use the phone very much.

More if the phone is nearly always in standby.
Less if you are doing screen intensive stuff for several hours (web browsing, gaming, continual twitter use, whatever).

Those large hi-res screens and the apps to fill them eat power.

Re:And yet, somehow, it's WORKING!? (1)

Locke2005 (849178) | more than 3 years ago | (#34757740)

More like "battery dies withing 45 to 90 minutes" if you use the phone for turn-by-turn navigation. Nothing like turning on display, CPU, GPS, 3G radio, and audio on full time to run the battery down quick.

Re:And yet, somehow, it's WORKING!? (1)

Anonymous Coward | more than 3 years ago | (#34757376)

OMG Android is making a play that's designed to let lower cost, highly capable devices force design choices that make faster, better phones still work like shit? How horrible is that?

FTFY.

Re:And yet, somehow, it's WORKING!? (3, Insightful)

BitZtream (692029) | more than 3 years ago | (#34757462)

OMG Android is making a play that's designed to let lower cost, highly capable devices subsist in the marketplace? How horrible is that?

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:And yet, somehow, it's WORKING!? (1)

Locke2005 (849178) | more than 3 years ago | (#34757708)

The iPhone had flaws, such as the lack of true multitasking, which were/are being fixed. Android also has flaws, which were/are being fixed. Yes, the Android ecosystem has a disadvantage in that it is subject to fragmentation, and the iOS ecosystem has a disadvantage in that Apple tries to exert too much control over developers. I expected Android to catch up with iOS much more quickly than it did; that was my mistake. By most reports, Froyo is the first Android release that is really ready for prime time -- unfortunately my G1 won't run it without some serious kludging.

Re:And yet, somehow, it's WORKING!? (0)

Anonymous Coward | more than 3 years ago | (#34757526)

Samsung LG Optimus??? Which is it? Samsung or LG?? Have Samsung and LG done a merger on the quiet? of course I am being facetious

As far as I was aware it was the LG Optimus...

Re:And yet, somehow, it's WORKING!? (0)

Anonymous Coward | more than 3 years ago | (#34757530)

The tone of your post made me vomit in my mouth a little. Please calm down.

Using hardware features better than emulation (0)

Anonymous Coward | more than 3 years ago | (#34757218)

Google engineers dismiss the desire for hardware-accelerated compositing

It that one engineer or more than one? Because one can make a mistake, but more than one, that would be a fail! I don't care what hardware does, ASIC solution is always better than emulation. I have to agree with Charles Ying - "On mobile, power efficiency is king"

Yet more Java bullshit (0)

Anonymous Coward | more than 3 years ago | (#34757266)

Man I hate Java programmers. They're always have to work around the limitations of that craptacular system and act like it's a good thing. No, no it's not. It's a broken, slow, poorly designed piece of crap.

Feeding the what? (4, Informative)

Big_Mamma (663104) | more than 3 years ago | (#34757280)

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.

Re:Feeding the what? (1)

dgatwood (11270) | more than 3 years ago | (#34757618)

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.

Odd, I've never noticed such problems in Mac OS X, even though every window in the OS is composited by the GPU. Maybe it's not so much that GL is inherently flawed so much as that the Windows implementation was hobbled by Microsoft so that game developers would use DirectX instead.

Re:Feeding the what? (1)

Locke2005 (849178) | more than 3 years ago | (#34757652)

On my Android G1 (which can only run Android 1.6), occasional long pauses before responding to touch input IS a problem. But I assumed that was fixed on newer phones with faster CPUs running Froyo or Gingerbread. I haven't seen any problems on the Color Nook, which is really just a cheap Android tablet device. Anybody have experience with the newest Android releases that can say whether or not these problems are already fixed?

Given that phones are still an 'embedded' platform (1)

scorp1us (235526) | more than 3 years ago | (#34757318)

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.

Re:Given that phones are still an 'embedded' platf (0)

Anonymous Coward | more than 3 years ago | (#34757726)

I never understood why anyone would want to interpret byte-code on a battery powered device.

What processor architecture should android have chosen to be stuck with? Bytecode allows you to change in the future without recompiling your apps, and the threat of change allows phone makers to push chip suppliers on price and power.

Also Poor compared To Symbian Battery life ..... (1)

thaig (415462) | more than 3 years ago | (#34757370)

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.....

Average? (1)

grumpyman (849537) | more than 3 years ago | (#34757372)

Well, as expected, Android is targeted at average mass consumers, so average battery life is acceptable. What gives?

GC vs. temp objects (1)

ThePhilips (752041) | more than 3 years ago | (#34757472)

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.

Re:GC vs. temp objects (1)

Locke2005 (849178) | more than 3 years ago | (#34757582)

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.

You're forgetting InterLisp (which probably is best forgotten). When Xerox released the InterLisp D machines, even files were garbage collected, meaning that if you deleted a large file, the machine went into a 10 minute garbage collection cycle, effectively blocking it from doing anything else. I'm sure there are other languages that use poorly-designed GC as well. I've never really liked garbage collection, but the alternative is to use IBM MVS like static preallocation of a "dataset" fpr everything. This guarantees predictable behavior, at the expense of using a lot more memory -- but memory is dirt cheap these days. (IBM used to do it for a different reason: they made huge profits on the disk drives.)

doesn't matter (1)

LodCrappo (705968) | more than 3 years ago | (#34757580)

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.

Testing (1)

hey (83763) | more than 3 years ago | (#34757584)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?