interesting info on Android GUI GPU acceleration

[zerocool84]

Part of what makes Fandroids happy is the fact they can spend months hacking on their device and how insanely hard changing what should be simple things can be. What you suggested about being able to install CM7 on any device is great, but I honestly think a lot of the Fandroids would frown upon it. I chat with many who like to brag about how much skills they have, if they could pull off a custom rom on any phone with no effort they'd be unhappy. I truly believe what the average person would see as a pita is the average Fandroids pleasure. I spent the better part of 4 weeks hacking on my EVO to hell to squeeze every second of battery life out of it I could. So I guess I fall in the Fandroid category lol.

And for years and years, iFans had to hack their phones for basic things like multitasking, skins, decent notifications, etc the list goes on. They're all the same.

 

[QueBert]

And for years and years, iFans had to hack their phones for basic things like multitasking, skins, decent notifications, etc the list goes on. They're all the same.

But the difference is with an iPhone you have nothing to take into consideration other than maybe what version of iOS it's running. With Android there are endless handsets with different builds of Android, custom shit like sense or touch ui. It's MUCH more difficult and time consuming to do things to an Android phone.

 

[Suspicious-Teach8788]

And for years and years, iFans had to hack their phones for basic things like multitasking, skins, decent notifications, etc the list goes on. They're all the same.

Okay, this is two different issues. The reason iOS lacked certain things like multitasking, skins, "decent notifications," etc. is because of how iOS was designed.

Hacking it to bring it more features is like Android lacking decent copy/paste support til now, lacking a decent keyboard til ICS, lacking a lot of other crap that CyanogenMod was created.

But I digress. This is completely BESIDES the point.

My issue was that fragmentation is slowing Android down. In the case of CyanogenMod, a LOT of effort is spent trying to make it work across multiple devices. It's reinventing the wheel with every device practically. I mean look at CM7 for the SGS2 when it was final. It's nowhere near the polish and completeness as CM7 was for say a Nexus One or Nexus S or a SGS1. It takes a lot of effort to make the ROMs work across a gazillion phones.

The solution obviously isn't to move to a single phone, but I'm certain a balance can be struck. It's not like we have to totally reinvent Windows to deal with Gigabyte motherboards versus Asus motherboards after all.

 

[gorcorps]

Fragmentation, also a buzzword that hasn't meant a thing in the real world and has only affected a very tiny percentage of people.

The people in the 10 cent android app thread beg to differ. There's still many people out there who have "incompatible devices" for many apps. Just because it hasn't affected you doesn't mean it's a small problem.

 

[Dulanic]

Okay, this is two different issues. The reason iOS lacked certain things like multitasking, skins, "decent notifications," etc. is because of how iOS was designed.

Hacking it to bring it more features is like Android lacking decent copy/paste support til now, lacking a decent keyboard til ICS, lacking a lot of other crap that CyanogenMod was created.

But I digress. This is completely BESIDES the point.

My issue was that fragmentation is slowing Android down. In the case of CyanogenMod, a LOT of effort is spent trying to make it work across multiple devices. It's reinventing the wheel with every device practically. I mean look at CM7 for the SGS2 when it was final. It's nowhere near the polish and completeness as CM7 was for say a Nexus One or Nexus S or a SGS1. It takes a lot of effort to make the ROMs work across a gazillion phones.

The solution obviously isn't to move to a single phone, but I'm certain a balance can be struck. It's not like we have to totally reinvent Windows to deal with Gigabyte motherboards versus Asus motherboards after all.

Apples and Oranges here. A complete ROM(CM) is completely different from applications that are being referred to with fragmentation. CM has to be completely rebuilt without driver code etc.. from the ground up. If the manufacturers released driver code, it would be much easier. Either way, this is so far off topic.

 

[Ancalagon44]

But the difference is with an iPhone you have nothing to take into consideration other than maybe what version of iOS it's running. With Android there are endless handsets with different builds of Android, custom shit like sense or touch ui. It's MUCH more difficult and time consuming to do things to an Android phone.

I have never understood the fragmentation issue. If you are building a rom, then by definition it will only ever support one device. If you are building an application, you dont need to worry about sense or touch ui or whatever, not relevant. You know that a particular version of android will expose a particular API and that is all that matters. Show me a 2.2 android device made by any manufacturer that will not run an application made for another android 2.2 device (*).

Yes there are hardware issues, like performance, but not hardware compatibility. Every android device supports openGL ES 2.0, for example.

 

[alent1234]

i've read skype didn't work on tegra 2 phones for months because nvidia didn't support NEON or something like that. took netflix months to get their app compatible with all phones. and every time something like this happens its always the new phones that get it first because they pay off the developer.

compare to iOS where an app comes out and supports every device on an iOS version with some limits

 

[alent1234]

Okay, this is two different issues. The reason iOS lacked certain things like multitasking, skins, "decent notifications," etc. is because of how iOS was designed.

Hacking it to bring it more features is like Android lacking decent copy/paste support til now, lacking a decent keyboard til ICS, lacking a lot of other crap that CyanogenMod was created.

But I digress. This is completely BESIDES the point.

My issue was that fragmentation is slowing Android down. In the case of CyanogenMod, a LOT of effort is spent trying to make it work across multiple devices. It's reinventing the wheel with every device practically. I mean look at CM7 for the SGS2 when it was final. It's nowhere near the polish and completeness as CM7 was for say a Nexus One or Nexus S or a SGS1. It takes a lot of effort to make the ROMs work across a gazillion phones.

The solution obviously isn't to move to a single phone, but I'm certain a balance can be struck. It's not like we have to totally reinvent Windows to deal with Gigabyte motherboards versus Asus motherboards after all.

iOS always had multi-tasking. apple only allowed it for their apps until iOS 4. you could always play the ipod app and do something else. it wasn't that big a deal until slacker started doing caching.

i tried the JB'd multitasking on an iphone 3G one time and it was so slow it made the phone unusable.

 

[ChAoTiCpInOy]

These threads always go back to the integrated vs fragmented. Android vs iPhone thing. Why can't we just talk about the issues or if we talk about the issues, why can't we just have a conversation without fighting?

 

[shortylickens]

https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s from the google team


What i made from that is: If a smooth UI is a requirement for you, dont expect ICS to be the savior you have been waiting for

I actually found it easier by just switching to WP7.

Dont need 10 million apps anyway. I spend most of my time in the top 3.
Calendar, email, and weather. And they all have live tiles so actually I spend very little time in apps period. Once quick view of the main screen is usually all I need.

 

[alent1234]

and on his google+ page andrew munn already said the mac blogs are taking what he wrote way out of context

 

[runawayprisoner]

These threads always go back to the integrated vs fragmented. Android vs iPhone thing. Why can't we just talk about the issues or if we talk about the issues, why can't we just have a conversation without fighting?

Because it's like sports... people can't help but try to put the other team down and make their own team look good even though the current match isn't even about any of those teams.

Anyways, back to discussion about GPU acceleration...

The real important difference between these two screens is just that the Galaxy Nexus has 2.4x as many pixels that need to be drawn as the S2. This means that to achieve the same efficiency at drawing the screen, you need a CPU that can run a single core at 2.4x the speed (and rendering a UI for a single app is essentially not parallelizable, so multiple cores isn't going to save you).

This is where hardware accelerated rendering really becomes important: as the number of pixels goes up, GPUs can generally scale much better to handle them, since they are more specialized at their task. In fact this was the primary incentive for implementing hardware accelerated drawing in Android -- at 720x1280 we are well beyond the point where current ARM CPUs can provide 60fps. (And this is a reason to be careful about making comparisons between the Galaxy Nexus and other devices like the S2 -- if you are running third party apps, there is a good chance today that the app is not enabling hardware acceleration, so your comparison is doing CPU rendering on the Galaxy Nexus which means you almost certainly aren't going to get 60fps out of it, because it needs to hit 2.4x as many pixels as the S2 does.)

I think it is very worth noting that I have mentioned this several times in this forum during this time.

The end result, and we can sum it up, is this:

1) GPU acceleration is not easy to implement, especially considering the multiple GPU configurations that Android has to accommodate.

2) CPU is a much easier way to cover up for what inefficient coding that goes on in the background in Android, and is generally a more accepted solution.

However, and I'm quoting the passage above:

1) GPU acceleration's benefits are immediately recognizable on devices with fast-enough GPUs and slow CPUs. This is where the comparison with iOS and WinPhone 7 come in. Arguably, though, it only applies to iOS. WinPhone 7 might still be using the CPU elsewhere, and 1GHz Snapdragon CPU ain't so weak it can't cover 800x480 pixels at 60fps in some cases. iOS is where we can safely say that 800MHz Cortex A8 can't do it without a lot of GPU acceleration. And no, pray God, this isn't a jab at Android. It's a comparison.

2) Android engineers are only looking into GPU acceleration, and the consensus is that app developers have to recompile or rewrite their codes to take advantage of it. Looking deeper into this, it's basically saying that... they never had this level of completeness, and they are only able to bring it to their users now. In any case, if app developers aren't willing to recompile or target ICS, which is understandable because ICS doesn't have so wide an install base right now, then... we can pretty much guess how app support would be.

So, this is something I have always said... Android engineers have always had problems enabling GPU acceleration, and even at this stage of Android, version 4.0, they are still having troubles implementing it as a system-wide thing. They do recognize the benefits and implications of it as screen resolution keeps scaling up, but for better or worse, they just can't do it.

And again, this is not a jab at Android. But it is just a fact that Android doesn't have the same level of GPU acceleration as iOS or WinPhone 7, and there will always be circumstances where iOS and WinPhone 7 would be a lot smoother than Android. It's not the OS' fault, but rather, you can call it laziness on Google's part, but I think the end of the discussion is that Android at ICS is still not going to challenge iOS or WinPhone 7 in terms of interface performance.

On a side note, I find it amusing that Dianne mentioned the G Nexus on ICS can't match the smoothness on Galaxy S2 on Gingerbread in some cases because it has 2.4x more pixels to render in CPU in certain circumstances. But to backtrack, the resolution of G Nexus is 1280 x 720. G Nexus is arguably using a CPU that's about comparable to most Honeycomb tablets out there... at least those that have Tegra 2. In addition, Honeycomb tablets need to render a few more pixels, at 1280 x 800. What does that say about Honeycomb interface performance? Hm... I think she just debunked another mystery.

Reading Dianne's post (took me 2 days to actually analyze all of the hidden contents and hints in there), I think it's a very honest realization and also kind of a public apology for the aloof attitude that Android engineers have shown to the community regarding GPU acceleration and UI smoothness issues. She did not mention a lot of things, whether deliberately or not, but I can still read them by connecting sentences from one paragraph to the other. Likely Google top brass didn't want her to just flat out say that Android GPU acceleration sucks and that they need to do more work on it, but it's still a very honest explanation from her. I applaud this effort.

 

[VashHT]

Because it's like sports... people can't help but try to put the other team down and make their own team look good even though the current match isn't even about any of those teams.

Anyways, back to discussion about GPU acceleration...



I think it is very worth noting that I have mentioned this several times in this forum during this time.

The end result, and we can sum it up, is this:

1) GPU acceleration is not easy to implement, especially considering the multiple GPU configurations that Android has to accommodate.

2) CPU is a much easier way to cover up for what inefficient coding that goes on in the background in Android, and is generally a more accepted solution.

However, and I'm quoting the passage above:

1) GPU acceleration's benefits are immediately recognizable on devices with fast-enough GPUs and slow CPUs. This is where the comparison with iOS and WinPhone 7 come in. Arguably, though, it only applies to iOS. WinPhone 7 might still be using the CPU elsewhere, and 1GHz Snapdragon CPU ain't so weak it can't cover 800x480 pixels at 60fps in some cases. iOS is where we can safely say that 800MHz Cortex A8 can't do it without a lot of GPU acceleration. And no, pray God, this isn't a jab at Android. It's a comparison.

2) Android engineers are only looking into GPU acceleration, and the consensus is that app developers have to recompile or rewrite their codes to take advantage of it. Looking deeper into this, it's basically saying that... they never had this level of completeness, and they are only able to bring it to their users now. In any case, if app developers aren't willing to recompile or target ICS, which is understandable because ICS doesn't have so wide an install base right now, then... we can pretty much guess how app support would be.

So, this is something I have always said... Android engineers have always had problems enabling GPU acceleration, and even at this stage of Android, version 4.0, they are still having troubles implementing it as a system-wide thing. They do recognize the benefits and implications of it as screen resolution keeps scaling up, but for better or worse, they just can't do it.

And again, this is not a jab at Android. But it is just a fact that Android doesn't have the same level of GPU acceleration as iOS or WinPhone 7, and there will always be circumstances where iOS and WinPhone 7 would be a lot smoother than Android. It's not the OS' fault, but rather, you can call it laziness on Google's part, but I think the end of the discussion is that Android at ICS is still not going to challenge iOS or WinPhone 7 in terms of interface performance.

On a side note, I find it amusing that Dianne mentioned the G Nexus on ICS can't match the smoothness on Galaxy S2 on Gingerbread in some cases because it has 2.4x more pixels to render in CPU in certain circumstances. But to backtrack, the resolution of G Nexus is 1280 x 720. G Nexus is arguably using a CPU that's about comparable to most Honeycomb tablets out there... at least those that have Tegra 2. In addition, Honeycomb tablets need to render a few more pixels, at 1280 x 800. What does that say about Honeycomb interface performance? Hm... I think she just debunked another mystery.

Reading Dianne's post (took me 2 days to actually analyze all of the hidden contents and hints in there), I think it's a very honest realization and also kind of a public apology for the aloof attitude that Android engineers have shown to the community regarding GPU acceleration and UI smoothness issues. She did not mention a lot of things, whether deliberately or not, but I can still read them by connecting sentences from one paragraph to the other. Likely Google top brass didn't want her to just flat out say that Android GPU acceleration sucks and that they need to do more work on it, but it's still a very honest explanation from her. I applaud this effort.

I'm not sure how you came to the conclusion that this is some apologist article for cocky android engineers, it's a technical article debunking the myth that gpu acceleration is the cure-all for a laggy UI. It's NOT saying android GPU acceleration is worse than iOS or WP7 there is nothing in the article saying that or anything close to it. You're reading into it WAY too much and it's almost like you spent 2 days trying to find some way to twist the article to bash android.

EDIT: Here is a quote from Dianne totally contradicting your conclusion actually:

From Articel:Edit: there have been a number of comments treating this as being written as an excuse for Android or not mattering to users or such. I'd just like to clarify that I wrote this solely to address a lot of incorrect information that I see posted around the web as truth. This is no attempt to excuse anything, and it is solely for those who already have an interest in writing and reading the often factually incorrect technical information out there

As you can see this was purely a technical article, she's not trying to apologize or excuse anything.

 

[runawayprisoner]

I'm not sure how you came to the conclusion that this is some apologist article for cocky android engineers, it's a technical article debunking the myth that gpu acceleration is the cure-all for a laggy UI. It's NOT saying android GPU acceleration is worse than iOS or WP7 there is nothing in the article saying that or anything close to it. You're reading into it WAY too much and it's almost like you spent 2 days trying to find some way to twist the article to bash android.

EDIT: Here is a quote from Dianne totally contradicting your conclusion actually:

From Articel:Edit: there have been a number of comments treating this as being written as an excuse for Android or not mattering to users or such. I'd just like to clarify that I wrote this solely to address a lot of incorrect information that I see posted around the web as truth. This is no attempt to excuse anything, and it is solely for those who already have an interest in writing and reading the often factually incorrect technical information out there

As you can see this was purely a technical article, she's not trying to apologize or excuse anything.

Nope. Like I said, I'm not bashing Android. Does everything that is bad about Android have to be bashing?

Anyways, read your own quote, please.

She said she isn't trying to "make excuse". In other words, she's being honest, and the information is laid bare.

there have been a number of comments treating this as being written as an excuse for Android or not mattering to users or such

She's saying that the article is not written as an excuse for Android, or in other words, she's not denying the facts being presented. I'm not twisting her words. I'm simply relaying her information.

If it's somehow become "bashing Android", then I think this is about the end of the discussion. Every time this was brought up, people either quoted "Android has always had GPU acceleration" or "you're just bashing".

But the fact is that Android is lacking in this department, and I believe myself and many others would like to see this problem rectified so that Android can become a better OS moving forward.

If you are satisfied with Android the way it is right now, then good for you. But I would like to see it become better.

 

[VashHT]

Nope. Like I said, I'm not bashing Android. Does everything that is bad about Android have to be bashing?

Anyways, read your own quote, please.

She said she isn't trying to "make excuse". In other words, she's being honest, and the information is laid bare.



She's saying that the article is not written as an excuse for Android, or in other words, she's not denying the facts being presented. I'm not twisting her words. I'm simply relaying her information.

If it's somehow become "bashing Android", then I think this is about the end of the discussion. Every time this was brought up, people either quoted "Android has always had GPU acceleration" or "you're just bashing".

But the fact is that Android is lacking in this department, and I believe myself and many others would like to see this problem rectified so that Android can become a better OS moving forward.
QUOTE]

Honestly it sounds like you're bashing when you say things like, "Likely Google top brass didn't want her to just flat out say that Android GPU acceleration sucks and that they need to do more work on it, but it's still a very honest explanation from her."

She isn't saying that, she's trying to clear up some misinformation on GPU acceleration being the magic fix for a smooth UI. She doesn't say anywhere that Android GPU acceleration is lacking or "sucks" compared to iOS or WP7. She is saying there is more to it and GPU acceleration is not the sole reason for a smooth UI.

I don't even use Android but I would like to see it reach the level of iOS or WP7 in terms of responsiveness because I used to use Android and I liked a lot about it.

 

[runawayprisoner]

Honestly it sounds like you're bashing when you say things like, "Likely Google top brass didn't want her to just flat out say that Android GPU acceleration sucks and that they need to do more work on it, but it's still a very honest explanation from her."

She isn't saying that, she's trying to clear up some misinformation on GPU acceleration being the magic fix for a smooth UI. She doesn't say anywhere that Android GPU acceleration is lacking or "sucks" compared to iOS or WP7. She is saying there is more to it and GPU acceleration is not the sole reason for a smooth UI.

I don't even use Android but I would like to see it reach the level of iOS or WP7 in terms of responsiveness because I used to use Android and I liked a lot about it. That being said she is not saying that there is a problem with hardware acceleration of Android, she's trying to clear up the idea that adding hardware acceleration is going to magically make Android buttery smooth.

I think you need to read it again and not just read what people have posted.

Like I mentioned, she is not trying to clear up the idea that adding hardware acceleration is going to make Android buttery smooth. That's not the point.

She is trying to make several points:

1) The complexity of adding GPU acceleration to certain drawing operations on Android doesn't yield favorable results, the way they have tried it. Using the CPU is still far simpler and consumes far less resources. Again, based on the way they are doing it. In other words, some current GPUs are not fast enough for them to do a full GPU-accelerated interface and keep 60fps smooth. Tegra 2 included. And once again, based on the way they are doing it.

2) As resolutions scale up, to the point of 720p like on the G Nexus, GPU acceleration will start to show results (and this may seem contradictory to what she just said, but it's actually just adding on), as current ARM performance likely can't keep up anymore. That's why ICS is introducing GPU acceleration, though it's a mixed bag because as mentioned in point 1, some GPUs are just not fast enough to do what they are trying to do.

3) A super fast single-core CPU is still more favorable to Android in its current state because the majority of applications that were not compiled or made with ICS in mind still rely heavily on the CPU for drawing operations.

Those are the 3 main points that I have drawn from reading her entire response. Word by word.

She did say that hardware acceleration isn't the magic to help, but she also went deeper into the reasons and one of them being that current GPUs are just not fast enough for her team.

But again, as resolution scales up, like... above 800 x 480, then the CPU will start to show its limitations, and then they have no choice but to use the GPU, and that's where ICS comes in. But current apps have to be recompiled or remade with ICS in mind to take advantage of the new capability.

I just repeated those points twice, but I hope it's clear now? She definitely said what you just wrote, but that's not the end of her sentence. There were more...

I'm actually very sensitive to this subject because of Android engineers' past attitude toward it. They were very aloof about whether it's there or not, and the actual technical reasons behind it were always not very clear.

Dianne's is the very first response from the Android team that actually tackles the issue head-on, but as expected, it still has sentences that are cut short to hide the precise meaning and exact reasoning behind certain points. It's not important what she is trying to state, but more important what she is trying to avoid writing as this is a very critical public response that may or may not damage the image of Android, and as you said, it might appear like bashing when interpreted the wrong way.

But at the end of the day, I think it's a very critical issue, and as Android moves forward, it needs to be addressed.

 

[BenSkywalker]

She clearly didn't dumb it down enough, a whole bunch of people here still aren't comprehending what she is saying.

GPU acceleration is frequently *inferior* to using the CPU on older hardware. While she doesn't throw them under the bus, I will- IT makes utter garbage drivers that are an embarassment to the industry. They steal a ton of system RAM(8MB a pop) for a simple task that takes kilobytes worth of data to handle. For phones that have very limited amounts of RAM, say the OG Droid as an example, consuming 8MB of system RAM per window open could get ugly fast(app drawer, a couple of widgets, live background and you are about out of RAM with typical tasks running).

For the Tegra2 devices- they don't have enough raw pixel fill for 720p with too many layers of windows and maintaining 60Hz(although it should still handle 30FPS easily even in worse case, so 'stuttering' that people talk about in HC isn't a fill rate issue).

But the fact is that Android is lacking in this department, and I believe myself and many others would like to see this problem rectified so that Android can become a better OS moving forward.

If someone offered me Android, without widgets forever, but assured to run at 120FPS always- I'd tell them to go to hell. And believe me that is the truth.

 

[alent1234]

apple has been doing GPU GUI acceleration for a while. i keep hearing how android phones always beat iphones on specs. something doesn't compute. especially the tegra 2 and later. all the hype here about how it's so amazingly fast

 

[runawayprisoner]

If someone offered me Android, without widgets forever, but assured to run at 120FPS always- I'd tell them to go to hell. And believe me that is the truth.

And I agree. I'd tell them the same.

But the problem is... I want to have my cake... and eat it too.

Screen resolution is going to scale up exponentially next year, and the year after, so I think this is a very critical feature for Android to have.

We are going to have faster GPUs and faster CPUs by next year, so there is no reason for Android to keep dumbing itself down for the slower hardware.

 

[soccerballtux]

She clearly didn't dumb it down enough, a whole bunch of people here still aren't comprehending what she is saying.

GPU acceleration is frequently *inferior* to using the CPU on older hardware. While she doesn't throw them under the bus, I will- IT makes utter garbage drivers that are an embarassment to the industry. They steal a ton of system RAM(8MB a pop) for a simple task that takes kilobytes worth of data to handle. For phones that have very limited amounts of RAM, say the OG Droid as an example, consuming 8MB of system RAM per window open could get ugly fast(app drawer, a couple of widgets, live background and you are about out of RAM with typical tasks running).

What this article basically tells us is that Android was not designed properly, and it's too late to go back.
You can thank having the whole thing on Java for the 8MB per app issue regarding enabling OpenGL ES. If the ARM CPUs included hardware virtualization support we could map the Java footprint for all the VMs to the same physical memory spaces, and including the OpenGL in every app wouldn't matter. That would actually free up enormous portions of RAM-- about 10MB per app you have running.

 

[VashHT]

I think you need to read it again and not just read what people have posted.

Like I mentioned, she is not trying to clear up the idea that adding hardware acceleration is going to make Android buttery smooth. That's not the point.

She is trying to make several points:

1) The complexity of adding GPU acceleration to certain drawing operations on Android doesn't yield favorable results, the way they have tried it. Using the CPU is still far simpler and consumes far less resources. Again, based on the way they are doing it. In other words, some current GPUs are not fast enough for them to do a full GPU-accelerated interface and keep 60fps smooth. Tegra 2 included. And once again, based on the way they are doing it.

2) As resolutions scale up, to the point of 720p like on the G Nexus, GPU acceleration will start to show results (and this may seem contradictory to what she just said, but it's actually just adding on), as current ARM performance likely can't keep up anymore. That's why ICS is introducing GPU acceleration, though it's a mixed bag because as mentioned in point 1, some GPUs are just not fast enough to do what they are trying to do.

3) A super fast single-core CPU is still more favorable to Android in its current state because the majority of applications that were not compiled or made with ICS in mind still rely heavily on the CPU for drawing operations.

Those are the 3 main points that I have drawn from reading her entire response. Word by word.

She did say that hardware acceleration isn't the magic to help, but she also went deeper into the reasons and one of them being that current GPUs are just not fast enough for her team.

But again, as resolution scales up, like... above 800 x 480, then the CPU will start to show its limitations, and then they have no choice but to use the GPU, and that's where ICS comes in. But current apps have to be recompiled or remade with ICS in mind to take advantage of the new capability.

I just repeated those points twice, but I hope it's clear now? She definitely said what you just wrote, but that's not the end of her sentence. There were more...

I'm actually very sensitive to this subject because of Android engineers' past attitude toward it. They were very aloof about whether it's there or not, and the actual technical reasons behind it were always not very clear.

Dianne's is the very first response from the Android team that actually tackles the issue head-on, but as expected, it still has sentences that are cut short to hide the precise meaning and exact reasoning behind certain points. It's not important what she is trying to state, but more important what she is trying to avoid writing as this is a very critical public response that may or may not damage the image of Android, and as you said, it might appear like bashing when interpreted the wrong way.

But at the end of the day, I think it's a very critical issue, and as Android moves forward, it needs to be addressed.

Well I agree with the things you said here, I guess it just sounded bad (mainly your conclusion) the way you worded it in your first post.

 

[runawayprisoner]

Well I agree with the things you said here, I guess it just sounded bad (mainly your conclusion) the way you worded it in your first post.

I guess I should have clarified.

But at the same time, it's not like politics are not completely involved in posts like these. I think that's the main reason for the lengthy and roundabout technical response.

If she just came out with "we're sorry, we screwed up. Now we need more powerful GPUs for this to work right", then it'll surely look bad for Android, and Google's top management wouldn't want that.

If she came out with "we're not doing anything wrong. GPUs just can't keep up with us". Then it's the same aloof response as last time, so more people will start complaining and more articles will pop up to speculate about exactly what the issue is.

She's walking a thin line between giving a satisfactory technical response, and one that causes some real damage. But the problem is still that this is something Android has lacked since day one, and that it's something that should be addressed for future builds moving forward. If this article doesn't exist prior to the move to higher resolution, then it'll just complicate matters.

With this article out, I think Google has accomplished 2 things:

1) It has given its customers an explanation regarding one of the long-standing issues with Android. One that is the subject of much debate, speculation, and discussion. With this out of the way, Android now at least has one good argument against other mobile OSes when it comes to interface performance. In the long standing battle, it's like they are yielding a bit of foot space so that they can propel forward when the time is right. (when GPUs are fast enough to do what the Android team wants to do)

2) If and when tablets jump to higher resolutions and they start to lag or stutter, then Google can cite this article and state that the manufacturer did not give satisfactory SoC performance, did not compile their apps to target ICS, or something along that line. Basically transferring the liability or shortcoming of the OS onto the manufacturer's inability to beef up their hardware.

Perhaps I'm just being paranoid, but Google is not exactly a do-no-evil company, and they have made some pretty questionable business moves in the mobile space as of late (acquiring Motorola, lending patents to HTC, and so on...).

 

[poofyhairguy]

But at the end of the day, I think it's a very critical issue, and as Android moves forward, it needs to be addressed.

After reading again I think it is being addressed, just like I thought it would, through time. The most important part is here:

Forcing hardware accelerated drawing upon existing apps will break a significant number of them, from subtly to significantly.

This is what I have been saying here for a while. iOS and WM7 have it better because from the start hardware accelerated drawing was standard. There was no breaking apps- these were parts of the original dev kit. Just like OSX it was baked in day 1.

Android is having to go through what Windows went through with Vista. None of the Windows OSes up to Vista had hardware accelerated drawing. XP was just like Android of today (even worse than Android actually), in that the CPU did most of the work. In 2006 when Vista hit the hardware wasn't ready yet except on the high-end, and the introduction of hardware accelerated drawing broke a significant number of apps. It was the same problem Google has today, but MS forced it down the throats of everyone and it ended up being a disaster for them.

Google could force hardware accelerated drawing, but that would harm its mature app market (that is already having to deal with new resolutions and SoCs), maybe beyond repair. At the very least if ICS forced it, it would be deemed a disaster, which Google can't afford.

So the solution is to wait it out. Wait until years from now when ICS is the oldest base any app uses and then not only will all apps be compatible but the hardware will be ready as well. Wait until today's SGS2 is tomorrow's total crap wouldn't want free phone.

With that said, maybe one solution is something taken from MS's handbook. When Vista hit a program that didn't like it, it had a way of turning off Aero to give the app a better chance to work. This worked horrible in Vista because without Aero the entire interface turned to XP-ish crap, but on full screen mobile apps you could do this without problem. So maybe in a year from now (rather than two) Google can release a version with it forced, but also with a fallback mode if users report issues with a particular app (they will need a system to manage that).

Honestly I think Google has bigger problems- dealing with many different resolutions (the zooming trick doesn't fix everything), dealing with purposeful market fragmentation (this 10 sale is a response to Amazon), and lawsuits.

 

[BenSkywalker]

You can thank having the whole thing on Java for the 8MB per app issue regarding enabling OpenGL ES.

What does that have to do with IT's drivers requiring 8MB of data space for each window in use? Even running non Java code the problem is still there.

What this article basically tells us is that Android was not designed properly, and it's too late to go back.

Really? Explain this out in detail, I would love to hear this. While you are at it, compare it to how iOS handles having multiple applications running on screen at once with multiple dynamic windows on a code level.

 

[MrX8503]

Apple has been working on GPU acceleration for a very long time. Its incorporated in their Mac OS and that carried over when they built iOS from the ground up. Steve Jobs being a perfectionist wanted the best scrolling/panning/zooming possible and its hard to believe that it was done back in 2007.

Google, being a company that develops great apps isn't really known for UI design. You can see this in their gmail/youtube/reader apps. Its cool to see that Google just gave these services a makeover though.

I'm quite certain that once they started their Android project, UI design was not close to being their top priority. Google wanted to release a functional OS and early designs of it was reminiscent of BBOS. We're on the verge of having 1080p+ in our pockets and Google is trying to address that.

At its core Android was never meant to be buttery smooth and so Google is trying to build on top of a base that's already been built. I think Google is trying very hard to get it right since HD smartphones are coming, but as we can see its not an easy task.