Does the DC support hardware acceleration for browser apps? I'm using Dolphin HD as my primary Reddit browser with the javascript from the reddit FAQ, and when it opens alot of images in the browser everything becomes very sluggish, doing redraws after you stop moving your finger instead of smoothly as you go.
The iPhone does this SO much better, because of hardware GPU acceleration. Does the DC GPU just not cut it, is it not engaged due to software issues (on Tweakstock 1.2), or maybe its just a lack of support altogether?
cmdrfrog said:
Does the DC support hardware acceleration for browser apps? I'm using Dolphin HD as my primary Reddit browser with the javascript from the reddit FAQ, and when it opens alot of images in the browser everything becomes very sluggish, doing redraws after you stop moving your finger instead of smoothly as you go.
The iPhone does this SO much better, because of hardware GPU acceleration. Does the DC GPU just not cut it, is it not engaged due to software issues (on Tweakstock 1.2), or maybe its just a lack of support altogether?
Click to expand...
Click to collapse
Yes it does, latest kernel PBJ does tweak the GPU up a little bit (+25). You can use either smoothness, V6 super charge,Thunderbold scripts or voodoo lag fixed to eliminate browser issue. First try xScope browser see it improves your legginess,.
buhohitr said:
Yes it does, latest kernel PBJ does tweak the GPU up a little bit (+25). You can use either smoothness, V6 super charge,Thunderbold scripts or voodoo lag fixed to eliminate browser issue. First try xScope browser see it improves your legginess,.
Click to expand...
Click to collapse
That's not what he was asking. I believe all recent Android revisions support GPU acceleration. It may just be a lack of RAM.
Sent from my SCH-I510 using xda premium
GPU acceleration is only in the stock browser that comes with the shipped ROM. If you modify it, it kills the acceleration from my experience. ICS has a different type of rendering in the browser to make it better/faster than what is available in GB. However, the fact that you're using Dolphin as the browser would have no effect on the browser included in the stock or custom ROM. If you want to know if Dolphin HD does GPU rendering, you'd have to contact them, or ask someone that knows as it would render independent of the included browser.
cmdrfrog said:
Does the DC support hardware acceleration for browser apps? I'm using Dolphin HD as my primary Reddit browser with the javascript from the reddit FAQ, and when it opens alot of images in the browser everything becomes very sluggish, doing redraws after you stop moving your finger instead of smoothly as you go.
The iPhone does this SO much better, because of hardware GPU acceleration. Does the DC GPU just not cut it, is it not engaged due to software issues (on Tweakstock 1.2), or maybe its just a lack of support altogether?
Click to expand...
Click to collapse
Actually the iPhone's smoothness, and Gingerbread's lack thereof, has more to do with the way Android was designed. Take a look at this video: http://www.youtube.com/watch?feature=player_detailpage&v=eWXxCFmKUlQ#t=40s
Notice how on the Vita, despite the rock-bottom rendering times, the browser runs at 60 fps and is perfectly smooth. The Vita OS prioritizes UI input over all other processes (it's a bit more complicated, but this is a close enough explanation).
Android unfortunately runs UI and apps at the same priority, so when an app is accessing CPU resources the entire system chugs. Also as you install more and more apps, your system will begin to experience increasing lag (although some shell scripts can mitigate the problem). Fixing this is not an easy job. You basically have to redesign the OS from the ground up, breaking compatibility with all previous apps.
This redesign issue is why RIM bought QNX and is now using a completely new operating system on their touch-screen devices, instead of redesigning Blackberry OS. It's also why Microsoft threw away Windows Mobile 6.5 and started from scratch with WP7. Same with Palm and webOS, as well as Nokia and MeeGo (before MSFT infiltrated them).
I was hoping Google would just chuck everything and go for broke with ICS, but they decided to play it safe. I personally would have preferred they do what RIM did with buying and implementing a brand new OS, and then using an emulation layer to enable backwards compatibility with old apps. I don't think running an entire OS in a VM on a device with constrained resources (CPU, GPU, and especially battery) makes a whole lot of sense.
But I guess we'll see how it all pans out in the end.
ambrar12 said:
Actually the iPhone's smoothness, and Gingerbread's lack thereof, has more to do with the way Android was designed. Take a look at this video: http://www.youtube.com/watch?feature=player_detailpage&v=eWXxCFmKUlQ#t=40s
Notice how on the Vita, despite the rock-bottom rendering times, the browser runs at 60 fps and is perfectly smooth. The Vita OS prioritizes UI input over all other processes (it's a bit more complicated, but this is a close enough explanation).
Android unfortunately runs UI and apps at the same priority, so when an app is accessing CPU resources the entire system chugs. Also as you install more and more apps, your system will begin to experience increasing lag (although some shell scripts can mitigate the problem). Fixing this is not an easy job. You basically have to redesign the OS from the ground up, breaking compatibility with all previous apps.
This redesign issue is why RIM bought QNX and is now using a completely new operating system on their touch-screen devices, instead of redesigning Blackberry OS. It's also why Microsoft threw away Windows Mobile 6.5 and started from scratch with WP7. Same with Palm and webOS, as well as Nokia and MeeGo (before MSFT infiltrated them).
I was hoping Google would just chuck everything and go for broke with ICS, but they decided to play it safe. I personally would have preferred they do what RIM did with buying and implementing a brand new OS, and then using an emulation layer to enable backwards compatibility with old apps. I don't think running an entire OS in a VM on a device with constrained resources (CPU, GPU, and especially battery) makes a whole lot of sense.
But I guess we'll see how it all pans out in the end.
Click to expand...
Click to collapse
I don't think it would require anything close to the level of rewriting that you are talking about here. We are running, for all intents and purposes, a Linux system with some custom UI layers. It's really no more special than Fedora Linux for x86 or PPC in that regard. Currently, I have mine running quite smooth...almost, but not quite, iPhone smooth...just by playing the renice game with process priorities (SysTune is great for this). As an end user with little desire to dig into the code myself, there's only so much I can do, but what I have done has virtually turned this into a new phone. If Google would change the way they handle the priority of certain basic apps...phone, systemui, media, launcher, etc...they could get the UI to that point by default.
The question then comes down to "why?" Why don't they do this? I can only imagine that there are consequences beyond what we as end users see. Me doing this to my individual phone is fine. If I cause issues, I have to deal with them and have no place to complain, but if Google did this by default and it caused issues on even 10 percent of phones, that's a much greater problem. This is the framework they have to work within. A complete rewrite would be completely outside the Android philosophy. They simply can't do it. RIM can do it because they are using proprietary systems, but Android is built around Linux. It's built around open source. We couldn't have the roms we have or the development we do without that, and Google wouldn't have the massive install base they do if they had a proprietary OS.
Ultimately, we as the end users just have to have faith that Google engineers who are far smarter and more knowledgeable than us have done what they have done for a reason, and the fact that they've decided to make this a mostly open system gives us the ability to tinker with it in ways that iOS, RIM, and Microsoft users can't. I'll take that over a complete rewrite any day.
They haven't done a rewrite because it would break backwards compatibility with all apps and require starting from scratch (with regards to features and such). Palm did this with webOS, but unfortunately didn't have the money or expertise to popularize their phones.
Also it's not just the UI priority, it's the whole running in the Dalvik VM issue. Have you ever lightly flinged your phone's screen to long-scroll a list, and noticed periodic "hiccups" that interrupt the smooth scrolling? That's Android's garbage collection, a unique feature of Java. Its purpose is to manage apps' memory allocations (there's more to it... but that's a good enough simplification), but an always on garbage collector drains battery. Since the entire OS runs in the VM, this tends to result in battery issues.
Unlike Palm, Google has the resources and human capital needed to redesign their OS. They also have a ton of carrier relationships across the globe. A redesign is merely a matter of willpower and risk aversion (and time). I'm still hoping Google is planning to wow everyone with a redesign they've been secretly working on for years.
*facepalm*
Apparently Google may end up releasing Android 5.0 in Q2 of this year: http://www.digitimes.com/news/a20120215PD209.html
I hope the report's suggestion that Google is appealing for dual-boot tablets isn't true. It would just seem... like why would the average person care about dual-booting? I know I would personally like it, but otherwise I doubt the second OS will see much use.
Dual boot to what?
Sent from my SCH-I510 using xda premium
kvswim said:
Dual boot to what?
Sent from my SCH-I510 using xda premium
Click to expand...
Click to collapse
Chrome OS
Sent from my HTC Vision using XDA App
xT4Z1N4TRx said:
Chrome OS
Sent from my HTC Vision using XDA App
Click to expand...
Click to collapse
Chrome OS?? chrome is a browser!. Dual boot between Android 5.0 and Windows 8 OS without shutting down the phone.
buhohitr said:
Chrome OS?? chrome is a browser!. Dual boot between Android 5.0 and Windows 8 OS without shutting down the phone.
Click to expand...
Click to collapse
Actually, google has been making a x86 OS called Chromium. Google chromebooks. It's basically a minimalistic laptop with chromium designed for cloud computing. It uses chrome as the browser, google docs for office etc.
Related
Can anyone with experiences or skillful developers answer my question?
every time when I opening up an application which i downloaded from the marketplace(non-stock apps),the speed was like i open an app on my iphone 3g,laggy and sluggish.
Honestly,the wp7 experience is not that great for me CURRENTLY and I don't have much money like M$,if not I could buy a second gen wp7 device.So,is it possible mango will fix everything up?or just the 1ghz processor is not good enough to run wp7?
I would prefer windows mobile 6.5 with wp7 animation&transition,then i'm good to go.
now this could be a novel question
but could it be the application itself? you even said native programs are smooth....
yea,true,native apps are buttery smooth.However,in other apps are so laggy.any solution for these problems?is it related to the APIs or the OS itself?
It's related to developers running business and dal code on the ui thread.
Give it time, devs will learn how to do it properly, especially with the new tools coming in VS soon.
1Ghz is plenty, and barely relative.
Is the Xbox fast enough? Of course, even 5 years after - because devs know how to utilise it properly, and build FOR the platform, not blame the platform for their inefficient code.
sylau90 said:
Honestly,the wp7 experience is not that great for me CURRENTLY and I don't have much money like M$,if not I could buy a second gen wp7 device.So,is it possible mango will fix everything up?or just the 1ghz processor is not good enough to run wp7?
Click to expand...
Click to collapse
Mango will fix a lot of it, developers need to fix some of it as well.
http://www.mobiletechworld.com/2011...overview-32bit-color-support-better-controls/
thanks mate @PG2G,thats really helpful and looks promising...can't wait for mango
domineus said:
now this could be a novel question
but could it be the application itself? you even said native programs are smooth....
Click to expand...
Click to collapse
Microsoft and oems cam use native code. Thirsting party developers cannot. That is why stock apps perform perfectly but third party apps suffer.
Developers can fix it by stripping out all the eye candy from their apps but then your left with a modern day textual user interface...
I hope they open up some native apps soon. Even in desktop apps the performance advantage odd an mfc oems or Delphi app is immediately apparent compared to their .net counterparts, even with beastly hardware.
Better hardware and os-level optimization will help the situation soon, though...
Sent from my SGH-T959 using XDA App
3rd party apps are all written in .NET managed code. When the app first loads, it needs to be compiled into native code and also instantiate inside a SliverLight player. Both take extra processing power and time compared to native apps that need to do neither tasks. I'm sure MS will continue to optimize the speed of JIT and SilverLight player. It will never match the native app load speed but it also won't bring down the entire OS if something goes wrong like the native apps potentially could do.
foxbat121 said:
3rd party apps are all written in .NET managed code. When the app first loads, it needs to be compiled into native code and also instantiate inside a SliverLight player. Both take extra processing power and time compared to native apps that need to do neither tasks. I'm sure MS will continue to optimize the speed of JIT and SilverLight player. It will never match the native app load speed but it also won't bring down the entire OS if something goes wrong like the native apps potentially could do.
Click to expand...
Click to collapse
.NET can precompile assemblies. That is what NGen does on the desktop. I'd find it quite odd if all of the base OS assemblies (entire .NET framework, etc.) isn't NGen'd on the phone. In fact, it would be pretty amatuer for Microsoft not to do that.
The Native Image Generator (Ngen.exe) is a tool that improves the performance of managed applications. Ngen.exe creates native images, which are files containing compiled processor-specific machine code, and installs them into the native image cache on the local computer. The runtime can use native images from the cache instead using the just-in-time (JIT) compiler to compile the original assembly.
Click to expand...
Click to collapse
Issues at play:
1. Older SoC with Older GPU in it: The phones would obviously perform better with a newer 1GHz Snapdragon or TI OMAP CPU. A Hummingbird would fly (too bad Samsung couldn't use it) with WP7.
2. Overreliance on Managed Code: This will get better as software is optimized more (the base platform) and WP7 users move to newer devices. But Managed Code, while not far behind Native code in many instances, just can't touch Native code in many places. You could develop MFC applications for Windows Mobile. .NET CF applications could not compete with those applications for performance.
3. Resources: Stock Apps do Multi-Task and in many cases you cannot truly exit them. If those apps are in the background eating up resources, then you will get worse performance.
Expanding on that, and of particular interest is RAM. Devices say they have 512 MB RAM but most devices have 128 MB dedicated to the GPU. The system and applications cannot use that for general purpose tasks. So while you may think you have 512 MB RAM, you really only have a configuration equivalent to 384 RAM with a 128 MB Graphics card in your phone. 128 MB is a large percentage of 512 (though a small number), and it can have performance implications on the device.
This is why HTC added an extra 64 MB RAM in their HD2/7 devices. The HD2/HD7 have 576 MB RAM, but 128 MB is dedicated to the GPU, so the system/apps really only has access to 448 MB of that.
4. Module dependency: Native Applications written in something like Visual C++ (MFC) or Delphi/C++Builder (VCL) don't really have that many module dependencies. That's why their load times are ridiculously fast. .NET applications have large module dependency chains and have to load in many cases a lot more libraries. There's a huge difference between loading the C++ Runtime and an MFC Shared Library (assuming the app was NOT statically compiled) and loading the app and having it daisy-chainload 20 different modules into memory.
Not to mention Native Applications can be multi-tasked much better because well written native apps tend to not use as much RAM.
On PCs this is less of a problem these days, since CPUs/RAM and even Hard Drives (SSD, etc.) are so fast and we have tons of RAM. But on phones, all of these factors can have factorably performance implications (excuse the redundancy).
But it is only that bad in certain types of apps - particularly those with long lists and tons of eye candy in the user interfaces. It should get better with updates.
P.S. There are ways to sandbox Native Apps, as well
Within the native OS its perhaps the best experience I have had across all smartphone platforms. Very well implemented. I just don't understand why almost all(im going with 95% at least) third party apps are so bad with this basic function. It feels like im working with a phone from 7 years ago. Can anyone explain the technical reasons for this problem.
yeahyeahyeah1981 said:
Within the native OS its perhaps the best experience I have had across all smartphone platforms. Very well implemented. I just don't understand why almost all(im going with 95% at least) third party apps are so bad with this basic function. It feels like im working with a phone from 7 years ago. Can anyone explain the technical reasons for this problem.
Click to expand...
Click to collapse
Hard to tell. I experienced these same issues. But since there are lots of apps out there that don't seem to suffer from bad scrolling, I'd rather blame the developers of laggy apps than the OS the apps are build on / for. Gotta say that almost every app I use on a regular basis has largely improved with the pre_mango beta.
Most apps are that way because they're poorly translated from android apps, others are in part due to the lack of APIs made available. Overall I think we'll see a lot of improvement when the full release of mango is out.
There are some performance issues with the listbox control in silverlight in Nodo and earlier.. they improved performance of that type of control in Mango.. so developers who are using it should automatically get an improvement.
Yeah, so far this seems to be a non issue in Mango. So just have patience.
The reason comes down to how the developer has implemented the listbox. If the listbox is simple, then it should run smoothly. If it's more complex, it may have a little lag. Often, listboxes have information that is being displayed as it's being downloaded (for example, a Twitter app may download the avatar image whilst the user is scrolling). In a basic implementation, the user may be downloading the image on the same thread as the UI. This results in the UI being unresponsive until the image is fully downloaded and displayed, which explains the lag. Other apps might use a smarter method and download only images that can currently be seen, instead of downloading every image in the listbox.
Even in a perfect implementation, there is a basic design flaw in the current system which means that the handling of the user's touch runs on the same thread as other UI actions. However, this is fixed in Mango as a new, dedicated thread is introduced which handles the user's touch on a separate thread, making it much more efficient out the box. So, in Mango, listboxes will be a lot more smoother
Hi guys,
I'm currently using an iPhone as my primary phone and android as a secondary one. I want to shift to windows phone (mango) but there are a few apps on the android not available on winmo which I can't live without. Is there any way to run android apps on the windows mobile the same way(or ANY way) its done on the blackberry play book?
Thanks
I don't think there's any. But there are alternate apps.
Android apps on WP7 would be incredibly difficult, though theoretically it could be done with enough effort.
Most Android apps use Dalvik (a dialect of Java). This is totally incompatible with the Silverlight/C# that WP7 apps use, but there are enough similarities between them that it might be possible to build a tool that either translates the Dalvik instructions to MSIL (the binary that compiling C# produces) at launch, or dynamically interprets it (the latter would be very slow, though).
However, even with purely Dalvik apps, there are other problems. WP7 apps are limited to a very restrictive sandbox, with no access to the vast majority of the filesystem (for example). Android apps, by comparison, have a great deal of access to the device they run on, so even a very simple app may expect to have permissions that wouldn't be available on WP7. Instead, attempts to access restricted parts of the filesystem would have to be "virtually" redirected within the sandbox. This is possible in many cases, but a *lot* of work to code and has all kinds of weird edge cases.
Additionally, Android apps have a very different runtime model from WP7 apps. The biggest change is in how they handle leaving the foreground; WP7 apps are either suspended or dehydrated, while Android apps often just keep running (they can elect to suspend, but aren't required to). WP7 does support background tasks (with strict limitations, at least if you stick to the official APIs), but moving the Android app runtime into those background tasks would be quite difficult.
Finally, there's the issue of hybrid apps (apps that use native code in addition to managed runtimes like Sliverlight or Dalvik). These are much more common on Android than on WP7 (at least, than on WP7 outside this webite). Android runs on a Linux kernel, using POSIX system calls and APIs. WP7 runs on a CE kernel, using win32 system calls and APIs. There's a very loose mapping from one to the other (see the Wine project for running Win32 apps on desktop Linux) but it adds a lot of overhead and would be another layer, at least as tricky as the managed part, to the difficulty of this project.
Short version: nope, sorry.
GoodDayToDie said:
Android apps on WP7 would be incredibly difficult, though theoretically it could be done with enough effort.
Most Android apps use Dalvik (a dialect of Java). This is totally incompatible with the Silverlight/C# that WP7 apps use, but there are enough similarities between them that it might be possible to build a tool that either translates the Dalvik instructions to MSIL (the binary that compiling C# produces) at launch, or dynamically interprets it (the latter would be very slow, though).
However, even with purely Dalvik apps, there are other problems. WP7 apps are limited to a very restrictive sandbox, with no access to the vast majority of the filesystem (for example). Android apps, by comparison, have a great deal of access to the device they run on, so even a very simple app may expect to have permissions that wouldn't be available on WP7. Instead, attempts to access restricted parts of the filesystem would have to be "virtually" redirected within the sandbox. This is possible in many cases, but a *lot* of work to code and has all kinds of weird edge cases.
Additionally, Android apps have a very different runtime model from WP7 apps. The biggest change is in how they handle leaving the foreground; WP7 apps are either suspended or dehydrated, while Android apps often just keep running (they can elect to suspend, but aren't required to). WP7 does support background tasks (with strict limitations, at least if you stick to the official APIs), but moving the Android app runtime into those background tasks would be quite difficult.
Finally, there's the issue of hybrid apps (apps that use native code in addition to managed runtimes like Sliverlight or Dalvik). These are much more common on Android than on WP7 (at least, than on WP7 outside this webite). Android runs on a Linux kernel, using POSIX system calls and APIs. WP7 runs on a CE kernel, using win32 system calls and APIs. There's a very loose mapping from one to the other (see the Wine project for running Win32 apps on desktop Linux) but it adds a lot of overhead and would be another layer, at least as tricky as the managed part, to the difficulty of this project.
Short version: nope, sorry.
Click to expand...
Click to collapse
That was quite disheartening for the OP
But I liked the thorough explanation.
for curiosity, which apps are you looking for?
Thanks a million for the detailed reply. I can give up on this now otherwise would have gone crazy searching. As for the apps I wanted to use Rako which basically controls the lighting in my house and creston media which controls my theatre. These I can't live without.
Additional ones would be anonymous email and sms bomb.( to bug my friends)
as for the lighting you got me..
but for media the xbox (if you have one) companion controls my whole xbox media experience from audio (zune), movies (integrated movie player streaming from my pc)..
What about this - http://wp7mapping.interoperabilitybridges.com/Library?source=Android
Can't this be used?!
buffalosolja42 said:
but for media the xbox (if you have one) companion controls my whole xbox media experience from audio (zune), movies (integrated movie player streaming from my pc)..
Click to expand...
Click to collapse
Crestron controls my theater as a whole i.e lights, projector, blu ray etc. I just need to press 1 button and lights dim, screen comes down, blurry starts playing and so on. For the xbox controller its only for the xbox
buffalosolja42 said:
but for media the xbox (if you have one) companion controls my whole xbox media experience from audio (zune), movies (integrated movie player streaming from my pc)..
Click to expand...
Click to collapse
drupad2drupad said:
What about this - http://wp7mapping.interoperabilitybridges.com/Library?source=Android
Can't this be used?!
Click to expand...
Click to collapse
Okay im a noob and i have noooo idea what that is
drupad2drupad said:
What about this - http://wp7mapping.interoperabilitybridges.com/Library?source=Android
Can't this be used?!
Click to expand...
Click to collapse
That is just for developers who want to port their app.
jessenic said:
That is just for developers who want to port their app.
Click to expand...
Click to collapse
Exactly! So yes, Android app can come to WP, only if developers are hard working to port it.
However, I haven't done more than making ROMs for WM, Themes for Android, but I am currently porting 2 apps from Android to WP. Honestly, all porting is made so dead easy that a little bit of English and Bing at hand, and you are off to a great start! It's slow process but anyone can port if they want to.
Another discussion where I posted a version of this led me to thinking that this might make for an interesting topic all on its own.
How would you envision a port of android made specifically for Desktop/Laptop environments, and do you think such an OS would be appealing to the average user?
_______________________________
As I envision it, ChromeOS should be folded into Android 4.0 and Google should build a version of the combined OS for Desktops.
The idea would be to create a common ecosystem of apps and usage environment accross multiple device categories, ad have it all interconnected through Google products and other apps running in the background.
I envision something that boots instantly right into ChromeOS while the rest of the Android system boots up in the background, thus allowing you virtually immediate cloud based functionality on the desktop. You could even choose to ONLY boot into chrome, say if you needed to look up something quickly online and didn't want to fully turn on a computer that has been turned off.
The chrome side of things would be very similar to ICS for tablets and would be deeply linked to all things google as well as relying on versions of the same Google apps that run on mobile, but optimized for ICS and taking advantage of larger screen dimensions. I envision touch interface to be retained for those who have touch sensitive screens, but also better keyboard and touchpad/mouse controls than currently exist. Lastly I would bundle a Google fork of Libre office specifically designed to have deep automatic integration with Google docs and Google+, but allowing users to have local editing control.
I would love to have such a system and have a common ecosystem between my phone, tablet and desktop/laptop, much how Apple currently does with IOs devices and MacOS and how Microsoft is planning to do with Windows 8 and WP8. unlike those ecosystems, this would run variants of the same OS, as opposed to different OSs made to work together, thus being able to take advantage of current built up knowledge and the existing android market.
Imagine if Google did the entire thing open sourced and released it to desktop and laptop OEMs.
A guy can dream right? If only there was a way to have a bunch of people pitch it to Google.
What do you guys think and how would you envision such an OS?
Android is already going to be merged with the Linux kernel in version 3.3 (with improved power management in 3.4)
nejc121 said:
Android is already going to be merged with the Linux kernel in version 3.3 (with improved power management in 3.4)
Click to expand...
Click to collapse
you sure about that? From what I've read Android is going to provide it's drivers and both Android and linux are going to provide patches to each other's kernels (with Power management being addressed in later versions of the linux kernel (3.4?). The Android kernel will remain (at least for now) a fork of the linux kernel.
Still that doesn't really address the subject of this thread.
Santeno said:
As I envision it, ChromeOS should be folded into Android 4.0 and Google should build a version of the combined OS for Desktops.
I envision something that boots instantly right into ChromeOS while the rest of the Android system boots up in the background, thus allowing you virtually immediate cloud based functionality on the desktop.
Click to expand...
Click to collapse
Yeah i too dream of Google using all the OS & games tech experience they have gained from Android to bootstrap a full desktop OS.
My personal fantasy is that the under no circumstances include any of the Chrome Cloud based nonsense. But focus quite heavily on games and multimedia, offer an OS that delivers content & gaming rather than try going head to head on productivity (where they would get owned).
Am not going to go into my objections to the cloud concept, lots of geeks my age & older well remember the mainframe model from the 70's and the cloud suffers many of the same inherent flaws IMHO.
I addition my fantasy involves ARM leveraging the experience with the multi-cores they have developed to produce an ARM desktop CPU arrays, as am a big fan or clusters and arrays, render farms etc.
I have to confess being serious i don't see either happening since both would be attempting to breaking into markets they are inexperienced in and where entrenched competitors already have a tough obstacle course laid out, plus pretty deep war chests.
But the main issue with a Google desktop OS, IMHO to succeed, i think it would have to be capable of some kind of half decent x86 emulation ........... But hey we are talking 'The Brothers Grimms Tales of Silicone Valley' here anyways.
Its possible to do so now, albeit not the same experince you get on your phone or tablet due to lack of driver support Its how i checked out 4.0 before I got it on my Asus Transformer Prime. Worth a try!
(Im new to XDA so I cannot post links, however google "android x86 download" and its the first link.)
There are ready is a port of android that works on desktops that these guys are working on over at http://www.android-x86.org/.
As we've seen, Android's flagship phones are equipped with some of the latest and best hardware; however, I read articles that mention Apple iOS takes full advantage of Apple hardware. The iPhone 6S with their A9 dual core processor including 2gb of RAM is able to compete with a Nexus 6P that has a hexacore Snapdragon processor with 3gb of RAM.
On the 6th iteration of Android (Marshmallow), why is Google unable to optimize their OS for their phone's hardware like Apple does?
Edit: My first post was never answered, so I'll try to get to the point. Does Apple's iOS communicate with the hardware more efficiently, whereas Android takes more steps to communicate with the hardware; therefore being less efficient?
It's not Google's hardware. Google does not make the Nexus line.
MrKhozam said:
It's not Google's hardware. Google does not make the Nexus line.
Click to expand...
Click to collapse
I'm not sure why I wrote that. You are correct, every Nexus phone has been manufactured by different companies. On a side note that might change. I read from a few tech news sources that Google is possibly going to take stricter control of the Nexus line and start manufacturing phones under their brand (same way Apple does).
My first post was never answered, so I'll try to get to the point. Does Apple's iOS communicate with the hardware more efficiently, whereas Android takes more steps to communicate with the hardware; therefore being less efficient?
iOS is developed explicitly for Apple's hardware. They know exactly what they have to do to take the full advantage of the hardware. They don't have to optimize the OS for other hardware because it only runs on Apple devices. In fact, Android runs on hundreds and thousands of different devices, which all have different hardware. Android needs to be optimized for the specified hardware but it is not so easy and also Android has to run on very different hardware without loosing compatibility.
The other thing that makes Android slower, is that applications run on a virtual machine. Applications on iOS are native and run directly.
Another point is that Android's responsiveness to the touch screen is worse than iOS' responsiveness. If you tap on something in iOS, it is immediately processed. In Android it takes some little time to process the touch event. Also you can tune up your Android system to increase responsiveness by increasing the allowed events per second on the windows manager and reducing the minimum pointer duration. You can also set the surface flinger velocity higher, so stuff on the screen would build up faster and render faster.
So the conclusion is:
In general, Android's responsiveness is not so good as iOS' responsiveness.
And iOS is made specially for Apple devices, so 100% hardware support is available.
Android needs to run on many many devices, so it is difficult to maintain 100% hardware support and compatibility as well as efficiency.
Hope that is clearly enough
"Specs" are also misleading. If specs on paper told the whole tale, AMD processors would be better than Intel, Mediatek would be better than Samsung and Qualcomm, and the Tegra K1 dual core used by the Nexus 9 would be laughably underpowered. iOS also doesn't need as much RAM as Android (remember, it's Linux based) for the way it handles memory. Don't go assuming that the "slow" speeds and fewer cores you see on Apple devices means that the hardware is inferior. If it were, they wouldn't get such impressive benchmarking scores.
xdvs23 said:
Another point is that Android's responsiveness to the touch screen is worse than iOS' responsiveness.
Click to expand...
Click to collapse
Is this because there's more 'layers' in Android's OS, so it takes more steps for it to create the response?
Thanks for taking the time to write out that long response. It was very well written and explained a lot for me.
This is the same reason game consoles stay relevant years after they come out with inferior hardware. Interesting how it works - better hardware but software can't take advantage cause of the potential audience
techmatlock said:
Is this because there's more 'layers' in Android's OS, so it takes more steps for it to create the response?
Thanks for taking the time to write out that long response. It was very well written and explained a lot for me.
Click to expand...
Click to collapse
It is because of the way android is made. Android was initially made for non-touchscreen devices with hardware keyboard. Later Google added the touch feature over the existing functionality instead of changing the whole system to optimize for touch devices.
---------- Post added at 10:43 AM ---------- Previous post was at 09:48 AM ----------
Planterz said:
"Specs" are also misleading. If specs on paper told the whole tale, AMD processors would be better than Intel, Mediatek would be better than Samsung and Qualcomm, and the Tegra K1 dual core used by the Nexus 9 would be laughably underpowered. iOS also doesn't need as much RAM as Android (remember, it's Linux based) for the way it handles memory. Don't go assuming that the "slow" speeds and fewer cores you see on Apple devices means that the hardware is inferior. If it were, they wouldn't get such impressive benchmarking scores.
Click to expand...
Click to collapse
Do you mean that android is linux based or iOS? Keep in mind that Android uses a modified linux kernel, which is optimized to be used with the Dalvik VM (or ART).
iOS is not based on linux. According to Wikipedia, iOS is based on Apple OS X, which uses the Darwin kernel, which is based on NeXTStep, and the top root of that is unix (BSD).
---------- Post added at 10:52 AM ---------- Previous post was at 10:43 AM ----------
Btw, Android has a delay when handling touch input events. When you tap on the touch screen, the kernel intercepts the touch event, notifies the system about it (window manager), then it is redirected to the currently active window and then it is handled by the corresponding application. The window manager is set to handle 30-60 (depends on the ROM) events per second by default, but I have adjusted it to 1200 and you really notice a difference. By setting the pointer duration to the minimum, the responsiveness is also increased. In that way, the delay is kept as small as possible, nearly coming to iOS level.
AFAIK iOS handles the input event directly. When you tap, the kernel redirects the event directly to the corresponding application which handles the input immediately. Also the performance in native iOS apps (they are written in Objective-C or Swift) is better than in android (written in Java, optionally expanded by C/C++ shared libraries).
Another important factor is that Android applications do all the stuff in the main UI thread by default. That means, whenever you tap on the screen, everything is handled in the UI thread, what causes that the UI is freezed for the time the application is processing the touch event. (Although this is a very very small hardly noticable timespan, it results in lag). Poorly developed android applications are very laggy because they don't use separate threads to do time intensive work.
In iOS instead, everything is handled in a separate thread by default. That means that when you tap somewhere, the UI would not freeze or lag during operations in the second thread. The result is, that you don't experience any lags while navigating through an user interface.
Conclusion is: Android is fast but it does not handle touch events so fast. Also, by default, operations are done in the main thread. On iOS they are handled separate.