or Connect
AppleInsider › Forums › Mobile › iPhone › Former Google intern explains why UI lag occurs more often in Android than iOS
New Posts  All Forums:Forum Nav:

Former Google intern explains why UI lag occurs more often in Android than iOS - Page 3

post #81 of 138
Quote:
Originally Posted by wakefinance View Post

...

+1.

Educated discussions are much better than blinded passion.
post #82 of 138
Quote:
Originally Posted by shompa View Post

The integrated approach to computers/phones/tablets have always been the best. But it have not been successful longtime because that people like diversity.

The integrated approach is Apple's main strength. IMO, it is catching on very well lately because it is so well developed lately. The iColud initiative is currently the ultimate in Apple interoperability.

It is a double edged sword for a consumer, however. They must trade convenience for lock-in. But since about 1945 or so, convenience has won every time.
post #83 of 138
Quote:
Originally Posted by wakefinance View Post

In most cases, it's your complete disrespect for anyone who chooses to use products that you yourself don't choose to use (namely Android products) that shows ignorance. It's not necessarily ignorance of the product, though I don't think you've extensively used the products you so frequently malign, but rather your ignorance of the basics of human nature. It's ignorance of the fact that different people have different needs. It's ignorance of the fact that different people value different things. And most of all it's ignorance of the fact that your unprovoked malice makes you a less credible individual.

As far as ignorance of the product goes, you demonstrated that in the portion of your post that I quoted the first time. Here you claim that Android devices respond "seconds after you press something." Ignorance. "...realtime music apps is something else that doesn't exist on Android, because of the terrible latency." Ignorance.

Just so you know, I think it is perfectly reasonable that someone could claim to have experienced a device exhibiting a consistent, seconds-long delay at some point, but the possibility for that having happened doesn't even remotely imply that it has happened, nor does it mean that one isolated case would be representative of the platform as a whole. Your unbridled hatred of all Android users and Android devices tells me that you likely have no evidence of such a device or such an experience, having merely created a scenario to project your own feelings on the world.

Sometimes it's difficult to tread around here even with a neutral stance. The reality distortion field is strong with some -- just keep this in mind at all times.
post #84 of 138
Quote:
Originally Posted by Shidell View Post

I'm very interested in what sort of a solution Google can come up with that allows operations to continue in the background while improving the stuttering that can occur, rather than simply wacking all operations for the input thread.

Multi-core processors? Isn't that a good reason to use them?
post #85 of 138
Quote:
Originally Posted by NotRs View Post

From a business standpoint Apple is off-and-on the biggest company in the world, and they took the time to do it right the first time.

Yeah it is not like modern (resistive or capacitive) touchscreen technology but the intended use is the same albeit issues with dirty sensors and poor resolution. My point is people need to stop acting like Apple created the touchscreen user interface in general. Too much credit goes to falsely implying Apple has invented technologies when the real strength lies in evolving old stale ideas and improving their function.
post #86 of 138
Quote:
Originally Posted by ConradJoe View Post

Multi-core processors? Isn't that a good reason to use them?

Yep, multi-core CPUs are a good solution--as long as the underlying framework is designed to take advantage of them. Right now the framework beneath Android is not, so while they help (because operations complete faster, thus less lag), it's not a perfect implementation like your idea of using a multi-core CPU to assist implies.

But yeah, that'd be one solution. I'm curious what they'll opt with.
post #87 of 138
Quote:
Originally Posted by shompa View Post

I think that Googles own "motorola" phones will be the ones that gets all these feautures. Here Google can choose the best SoC (something with PowerVR6) and really spank Apple.
...

Android phones do not need more processor and GPU power, they have plenty. (Though tablets will probably need as much as they can get for the time being.) It's all about fixing the software.
Quote:
Will they lock up Android more? Maybe do the MSTF way where anybody can manufacture the hardware, but MSFT tells them what hardware they have to use + have a locked App store.

There's no reason to. Android phones' problems aren't with the hardware. Immaturity of the OS explains a lot, manufacturer- and operator-specific tinkering explains the rest. If anything, Google should aggressively test phones to ensure they adhere to the Android API. For example, call recorder apps apparently work on few phones because many manufacturers do not correctly hand the call soundstream to an app as required by the API; this is exactly the kind of problem Google could easily force the manufacturers to fix.

In the long run, the biggest move I'd like to see from Google is streamlining the update pipeline and eventually cutting operators and HW manufacturers out of it. No reason why HTC, Samsung etc couldn't still offer their own tuned Android, but the user should at any time have an option to go completely vanilla. So for instance: you have a HTC with Sense UI. Android 5.0 hits. You choose to update directly to it from Google. HTC, your operator etc. have no way of preventing this. Three months later HTC has prepared their own 5.0 distribution, and you choose to update to that. This would result in the userbase staying roughly up to date, allay the fears of not getting more updates, and set a very concrete standard of quality for the manufacturers: unless the custom OS beats stock OS, the user bails.

It would be a retarded move for Google to prevent app sideloading. User freedom is the single biggest thing Android offers compared to iOS and Windows Phone.
post #88 of 138
Quote:
Originally Posted by Shidell View Post

Yep, multi-core CPUs are a good solution--as long as the underlying framework is designed to take advantage of them. Right now the framework beneath Android is not, so while they help (because operations complete faster, thus less lag), it's not a perfect implementation like your idea of using a multi-core CPU to assist implies.

But yeah, that'd be one solution. I'm curious what they'll opt with.

So is it feasible to improve multi-core usage at the OS level, and if so, would that obviate the need for legacy apps to be rewritten? How is Android currently not as "multi-core-able" as possible?

Anybody else have insight on how Android currently utilizes multi-core processors, and how the code is able to be improved?
post #89 of 138
Quote:
Originally Posted by kotatsu View Post

Or the lag on an iPhone 4 running iOS5. My iP4 is stupidly laggy since the update, it's almost like going back to my old iPhone 3G.

Once you kill the background apps, mainly games, your phone lags is gone. I had the same issue with my 3gs iOS5, now my 3GS is running great by deleting background apps.
post #90 of 138
Quote:
Originally Posted by ConradJoe View Post

So is it feasible to improve multi-core usage at the OS level, and if so, would that obviate the need for legacy apps to be rewritten? How is Android currently not as "multi-core-able" as possible?

Anybody else have insight on how Android currently utilizes multi-core processors, and how the code is able to be improved?

Yes, Android can be heavily modified to work with multi-core (or multi-cpu) systems. For example, the current iteration of Android runs the UI thread alongside other system threads, which are not necessary seperated by core or CPU. It's simply a high-priority thread, and other operations (like cellular connectivity) are equally high-priority.

Android could be redesigned so that the UI thread is always run on it's own core, with no other threads attached to that core. Alternatively, the UI thread could be elevated to a status below nothing else (which is how iOS operates), so that when the UI is being modified, everything else is slowed down (or stopped) to handle the UI. Further, Android could devise a system to spread the overall workload out evenly across all cores, but that may still give way to problems in the future as applications and Android's overhead increase.

I think the best thing that Google can do is to change the rendering pipeline--items drawn on screen are flattened by the CPU and sent off to the GPU for display. Android 3.0 (and of course, 4.0) are alleviating much of that by performing more work via the GPU (or Hardware Accelerating the operation), but there is a lot of room to improve. For example, rather than flatting views and mixing them around by the CPU before display via the GPU, Android could render each view as a flat texture stored in memory, which is simply applied by the GPU. Those operations are fast and lightweight, and akin to what Windows Aero does.
post #91 of 138
Quote:
Originally Posted by Neo42 View Post

That's just ridiculous. Apple only 'invented' the iOS touchscreen UI. Touchscreens had been around (with UIs underneath them) since the 80's. The HP-150 is likely one of the first personal computers incorporating a touchscreen interface.

Also, despite what many people would like to think, if Google is so desperately trying to steal the iOS UI than why is it so "crappy and laggy"? The UI philosophy is so drastically different it's difficult to understand why people still try to preach that Google has stolen anything at all. Android UI is flexible, customizable and dynamic (themes, widgets, custom launchers, etc). iOS UI is completely rigid and static (no themes, no widgets, one size fits all). The performance problems in Android are in some part related to this fact, as the overhead created in the Android environment is significant.

Do you know Microsoft release the Tablet PC on Nov. 2002? That is more than seven years ahead of iPad 1? If the touchscreen UI was known before iPhone then why Microsoft did not incorporate it into Tablet PC on Nov. 2002 or in subsequent updates?
post #92 of 138
Quote:
Originally Posted by tzeshan View Post

Do you know Microsoft release the Tablet PC on Nov. 2002? That is more than seven years ahead of iPad 1? If the touchscreen UI was known before iPhone then why Microsoft did not incorporate it into Tablet PC on Nov. 2002 or in subsequent updates?


Technically microsoft made a windows for pen computing back in 1991. Tablet pc in 2002 was thrown together.

Microsoft suffers from the has to be everything for everybody problem .Since apple controls the hardware they can do what they want.
post #93 of 138
Quote:
Originally Posted by Apple ][ View Post

And that is one of the main reasons why every Android device has sucked so far. Some pathetic people even go as far as denying that there is any lag on Android. They're either serial liars or they're blind.

On a touch screen device, all user interaction needs to be instantaneous, not seconds after you press something. And everything needs to be smooth, not jerky.

There's also another big thing that Android can not do well, it doesn't handle audio properly, and realtime music apps is something else that doesn't exist on Android, because of the terrible latency.

That is fascinating. I have experienced the same problems with my iPod Touch. The OS will lag swiping between app pages, presses don't register, the OS will just hang for no apparent reason.

As for the audio, still prefer the Zune HD audio. Its just a better sound. I don't even bother playing music on the Touch.
post #94 of 138
Quote:
Originally Posted by GalaxyTab View Post

Silly comment.

First of all, that is a HTC Android prototype, not a Google prototype. Secondly, Android is software. If software wasn't scalable and able to be used on different form factors iOS (which is derived from OSX) would not exist as it does today.

The earliest Android SDK and prototypes were designed for touch and physical interfaces and Android as it is today is fully usable using a dpad and hardware keyboard.

If software was designed to run on a blackberry type device and then they had to slap on a touch GUI at the last minute after seeing what Apple was putting out, it doesn't take a rocket scientists to see why this would result in unoptimized graphics.

iOS was designed from the ground up for touch. Andrioid was designed by keyboard/trackball and had a touch GUI slapped on top of it.
post #95 of 138
Quote:
"The device no longer feels natural. It loses the magic. The user is pulled out of their interaction and must implicitly acknowledge they are using an imperfect computer simulation. I often get lost in an iPad, but I cringe when a Xoom stutters between home screens," he said.

The jig is up. They've figured out the secret magic ingredient of iOS. I don't think Google doesn't care. The challenge for them will be the fact that they don't own the entire technology "stack": from chips to UI. I don't think that will change. Same case with Microsoft when it comes to Windows. Windows 7 has an "experience rating" which is a number that's supposed to quantify how well your hardware is supposed to work desktop applications. That number varies. With iOS or Mac OS X, the OS is developed more closely with the hardware in mind. The result is that the OS does not fail to utilize the underlying hardware to its full potential.

"Apple should pull the plug on the iPhone."

John C. Dvorak, 2007
Reply

"Apple should pull the plug on the iPhone."

John C. Dvorak, 2007
Reply
post #96 of 138
Quote:
Originally Posted by Shidell View Post

Yes, Android can be heavily modified to work with multi-core (or multi-cpu) systems. For example, the current iteration of Android runs the UI thread alongside other system threads, which are not necessary seperated by core or CPU. It's simply a high-priority thread, and other operations (like cellular connectivity) are equally high-priority.

Android could be redesigned so that the UI thread is always run on it's own core, with no other threads attached to that core. Alternatively, the UI thread could be elevated to a status below nothing else (which is how iOS operates), so that when the UI is being modified, everything else is slowed down (or stopped) to handle the UI. Further, Android could devise a system to spread the overall workload out evenly across all cores, but that may still give way to problems in the future as applications and Android's overhead increase.

I think the best thing that Google can do is to change the rendering pipeline--items drawn on screen are flattened by the CPU and sent off to the GPU for display. Android 3.0 (and of course, 4.0) are alleviating much of that by performing more work via the GPU (or Hardware Accelerating the operation), but there is a lot of room to improve. For example, rather than flatting views and mixing them around by the CPU before display via the GPU, Android could render each view as a flat texture stored in memory, which is simply applied by the GPU. Those operations are fast and lightweight, and akin to what Windows Aero does.

Good stuff. Thanks.

WRT your middle paragraph, I wonder whether your first alternative is possible on single-core processors? If not, is that why Android doesn't currently use that mode? Can it be installed to work that way only if a multi-core processor is available?

Apple's method makes sense, but I wonder if they are shooting themselves in the foot in the long run, as hardware improves.
post #97 of 138
Quote:
Originally Posted by Suddenly Newton View Post

Odd that when Microsoft dominated user experience, nobody was particularly sensitive about "smooth animation" and responsive UIs.

Not exactly true. One thing that Microsoft were always good at (eg XP and earlier) was a responsive UI. The processor may not have been fast, but the UI always was, and it was always very difficult explaining to people that a Mac running System 8/9 was actually faster, when the UI did drag. And badly.

So for instance, you could press on an icon and the Windows machine would be much quicker, however, when it came to rendering something in Photoshop, the Mac would blow the Windows machine away.

It was only when MS allowed woefully inadequate memory on Vista machines did they screw that responsiveness up, and we all know that that allowed the Mac back in.
post #98 of 138
Quote:
Originally Posted by Neo42 View Post

My point is people need to stop acting like Apple created the touchscreen user interface in general. Too much credit goes to falsely implying Apple has invented technologies when the real strength lies in evolving old stale ideas and improving their function.

But who is saying Apple invented touch screen user interfaces "in general"? I think you are misreading people who are crediting Apple for implementing and popularizing one of the best touch screen user interfaces yet applied to mobile computing devices. It does contain a number of original (and patentable) ideas. But touch screens have been around in GPS nav systems and automated teller machines for years.

"Apple should pull the plug on the iPhone."

John C. Dvorak, 2007
Reply

"Apple should pull the plug on the iPhone."

John C. Dvorak, 2007
Reply
post #99 of 138
Quote:
Originally Posted by ConradJoe View Post

Good stuff. Thanks.

WRT your middle paragraph, I wonder whether your first alternative is possible on single-core processors? If not, is that why Android doesn't currently use that mode? Can it be installed to work that way only if a multi-core processor is available?

Apple's method makes sense, but I wonder if they are shooting themselves in the foot in the long run, as hardware improves.

Yep, you're right. That's the catch.

You can make the UI smooth as glass if you dedicate all of your hardware to the UI first and foremost, which is what iOS does. Android takes a different approach and says, "Let's try to keep this as responsive as possible, but also perform work in the background so other things keep happening."

Both are interesting solutions. Android (generally) has more going on in the background, and can "keep working" while input is being handled--and as hardware improves, that only gets better. The problem is that this system is still subject to periodic stutters, even if minor, which are visually annoying.

For example, on my Evo 4G, the phone performs great. However, when I'm scrolling through a massive post on Google+, it will "stutter" every few seconds, as the UI thread is shared with the background processes. That stutter breaks the "immersion" that iOS users have.

It's an interesting problem, because if Android operated like iOS, then regardless of hardware available, everything else stops for the UI. 5x 4.0Ghz quad-core CPUs and 32 GB of RAM would all stop for the UI in iOS; Android would try to leverage everything as best it could, but at the sacrifice of ultimate smoothness and immersion.

I'm mixed on how I feel.. which is why I'm interested in what Google comes up with. Android J____ is going to be interesting.
post #100 of 138
Quote:
Originally Posted by Suddenly Newton View Post

But who is saying Apple invented touch screen user interfaces "in general"?

The poster I quoted earlier "Apple invented the touchscreen UI, Google is just trying to steal it" Also, there are plenty of Apple evangelists out there (particularly those defending all these ridiculous IP cases) who claim Apple invented all of the i-device technology that has become overwhelmingly popular in the past 4-5 years. Don't get me wrong, Apple has definitely made strides in applying the tech that is available.
post #101 of 138
Quote:
Originally Posted by Shidell View Post

For example, on my Evo 4G, the phone performs great. However, when I'm scrolling through a massive post on Google+, it will "stutter" every few seconds, as the UI thread is shared with the background processes. That stutter breaks the "immersion" that iOS users have.

Equally annoying is the "big empty space" you get when iOS tries to scroll into an area that the background process hasn't gotten around to rendering, then scroll back to an old area that has somehow been wiped out and needs to be re-rendered.
post #102 of 138
Quote:
Originally Posted by tinman0 View Post

Not exactly true. One thing that Microsoft were always good at (eg XP and earlier) was a responsive UI. The processor may not have been fast, but the UI always was, and it was always very difficult explaining to people that a Mac running System 8/9 was actually faster, when the UI did drag. And badly.

So for instance, you could press on an icon and the Windows machine would be much quicker, however, when it came to rendering something in Photoshop, the Mac would blow the Windows machine away.

It was only when MS allowed woefully inadequate memory on Vista machines did they screw that responsiveness up, and we all know that that allowed the Mac back in.

I have observed that when some Windows XP kernel threads (ring 0) gets scheduled constantly on all cores, Windows XP user input responsiveness will go to shit. The mouse cursor starts "skipping" across the screen because it is lagging so badly. Pressing Ctrl-Alt-Del will clear the desktop but the window to let you lock the screen or open task manager will never appear. If you click anything, it won't register for something like 1+ minutes! Anyway, I can repeatly cause this problem when running a particular plug-in, which I avoid using now.

I'm have noticed that Apple's close integration with the hardware had allowed them to take better advantage of that hardware. For example, the old Classic Mac OS sampled mouse input on every vertical retrace of the screen, which is 60Hz, while Windows OS originally didn't even require a mouse to use (though people rarely used it that way), oweing to it's DOS roots. And Windows mouse sampling was limited by the speed of the original PS/2 or serial ports that were used to attach mice, back in the 90s. Something like 40Hz, but it had nothing to do with how often the monitor image would refresh, so before USB mice were common, even mouse movement wasn't entirely smooth on Windows, even if it was usually imperceptible.

"Apple should pull the plug on the iPhone."

John C. Dvorak, 2007
Reply

"Apple should pull the plug on the iPhone."

John C. Dvorak, 2007
Reply
post #103 of 138
Quote:
Originally Posted by Neo42 View Post

Equally annoying is the "big empty space" you get when iOS tries to scroll into an area that the background process hasn't gotten around to rendering, then scroll back to an old area that has somehow been wiped out and needs to be re-rendered.

Yep, that's true. There really isn't a winning solution; I just perceive the problem on my end as worse. I'm sure I'd be equally annoyed if things didn't render until I didn't touch them.
post #104 of 138
Quote:
Originally Posted by Neo42 View Post

The poster I quoted earlier "Apple invented the touchscreen UI, Google is just trying to steal it" Also, there are plenty of Apple evangelists out there (particularly those defending all these ridiculous IP cases) who claim Apple invented all of the i-device technology that has become overwhelmingly popular in the past 4-5 years. Don't get me wrong, Apple has definitely made strides in applying the tech that is available.

I wrote the post. I also posted about Microsoft Tablet PC. Look at Microsoft Tablet PC carefully. User 'touches' the tablet's window elements like menus, scroll bars, buttons. That is all. Apple invented the touchscreen UI that you can move your finger on the screen to do something like unlock the phone. This is actually an extension of iPod scroll wheel that you can move your finger around to scroll the song list.
post #105 of 138
Quote:
Originally Posted by tzeshan View Post

I wrote the post. I also posted about Microsoft Tablet PC. Look at Microsoft Tablet PC carefully. User 'touches' the tablet's window elements like menus, scroll bars, buttons. That is all. Apple invented the touchscreen UI that you can move your finger on the screen to do something like unlock the phone. This is actually an extension of iPod scroll wheel that you can move your finger around to scroll the song list.


A man wiser than I once said:

"When you find yourself in a hole, the best thing to do is to stop digging".
post #106 of 138
Quote:
Originally Posted by tzeshan View Post

I wrote the post. I also posted about Microsoft Tablet PC. Look at Microsoft Tablet PC carefully. User 'touches' the tablet's window elements like menus, scroll bars, buttons. That is all. Apple invented the touchscreen UI that you can move your finger on the screen to do something like unlock the phone. This is actually an extension of iPod scroll wheel that you can move your finger around to scroll the song list.

What you're saying is Apple was the only company to think "Hey, you know what, we can make the DISPLAY change in response to touch input!" I used a windows mobile phone for many years and while the "touch" implementation was crap (mostly intended for stylus use) I definitely remember the UI responded to touch input. Apple made the response time tremendously better (near real-time). THAT is all. Aside, there was swipe to unlock before iphone. I won't bother looking it up for you.
post #107 of 138
OSX was designed around the Mach kernel, which NeXt Step used. OSX, however, is not NeXt although it borrows some of the design elements of the GUI. The whole genius of NeXt was it's initial design to be scalable and usable on many different architectures by using the Mach kernel.

Quote:
Originally Posted by alandail View Post

Funny out pre iPhone is used as a distinction when the iPhone is OS X, which is NeXTStep, which was designed in the 80s.

Certainly Apple designed Cocoa Touch specifically for the iPhone, but much of what is discussed here (i.e. caching object bitmaps) are things NeXTStep 1.0 did correctly. Which enabled things like live scrolling, live window movement, etc on the desktop with the same fluidity as the UI on iOS devices.
post #108 of 138
Quote:
Originally Posted by Neo42 View Post

What you're saying is Apple was the only company to think "Hey, you know what, we can make the DISPLAY change in response to touch input!" I used a windows mobile phone for many years and while the "touch" implementation was crap (mostly intended for stylus use) I definitely remember the UI responded to touch input. Apple made the response time tremendously better (near real-time). THAT is all. Aside, there was swipe to unlock before iphone. I won't bother looking it up for you.

Did you understand my point? What I mean is iOS responds to user move finger on the screen. You said the UI responded to touch input. This can be different from responding to moving finger. Without this Angry Birds will not function.
post #109 of 138
True, but it wasn't associated with an icon. You just swiped the phone on the bottom of the screen. Apple tied the swipe gesture to an icon. That is what Apple was given the patent for. Not the swipe to unlock, but the swipe to unlock tied to a GUI element.

Quote:
Originally Posted by Neo42 View Post

Aside, there was swipe to unlock before iphone. I won't bother looking it up for you.
post #110 of 138
Look at this video. About halfway through, this phone is using a swipe to unlock feature. It predates the iPhone. However, the difference with the iPhone is you don't have to remember the gesture because the phone shows you what to do.

Quote:
Originally Posted by tzeshan View Post

I wrote the post. I also posted about Microsoft Tablet PC. Look at Microsoft Tablet PC carefully. User 'touches' the tablet's window elements like menus, scroll bars, buttons. That is all. Apple invented the touchscreen UI that you can move your finger on the screen to do something like unlock the phone. This is actually an extension of iPod scroll wheel that you can move your finger around to scroll the song list.
post #111 of 138
Quote:
Originally Posted by TBell View Post

Look at this video. About halfway through, this phone is using a swipe to unlock feature. It predates the iPhone. However, the difference with the iPhone is you don't have to remember the gesture because the phone shows you what to do.

This is why I said Angry Bird would not function. Because you touch the bird (an icon) before moving the finger. Before iOS, Microsoft Tablet PC does not support it. Google steal it from iOS.
post #112 of 138
Quote:
Originally Posted by AbsoluteDesignz View Post

I agree with you and Android was obviously a rush job upon release (and suffers from it today) but from a business standpoint I feel they had no choice but to release early in order to even compete against the new juggernaut (Apple)

It's not iOS that would have killed them. It's Microsoft and Windows Phone.

As much as people keep thinking that Google is worried about Apple. It's not. Google is worried about MS. Androids get people on and locked in to the Google ecosystem. After that, even if you go iPhone, you'll probably still use GMail, Google Maps, Google Search, etc. But if you're a Windows Phone user, you might not use Google at all. That's what Google was worried about.

For all their disputes, most iPhones sold will still help put Google services in more hands. Windows Phones do not.
post #113 of 138
Quote:
Originally Posted by tzeshan View Post

Did you understand my point? What I mean is iOS responds to user move finger on the screen. You said the UI responded to touch input. This can be different from responding to moving finger. Without this Angry Birds will not function.

So what you are really saying is Apple refined the touch/response process to a more user friendly level. That's a lot different than saying "Apple invented the touch UI". Maybe it is semantics to you but to me (and others) it's a world of difference.
post #114 of 138
Quote:
Originally Posted by tzeshan View Post

This is why I said Angry Bird would not function. Because you touch the bird (an icon) before moving the finger. Before iOS, Microsoft Tablet PC does not support it. Google steal it from iOS.

You're just wrong here. There were "real time" responses to touch input before the iPhone. They just sucked. And according to this thread, they still do. So if Google mimic is so poor how again have they committed theft?
post #115 of 138
Quote:
Originally Posted by wakefinance View Post

In most cases, it's your complete disrespect for anyone who chooses to use products that you yourself don't choose to use (namely Android products) that shows ignorance.

Of course it's disrespect, that is my intent and goal. I have no use for Android trolls and Apple haters and I do happen to think that Android is an inferior platform.

Quote:
Originally Posted by wakefinance View Post

As far as ignorance of the product goes, you demonstrated that in the portion of your post that I quoted the first time. Here you claim that Android devices respond "seconds after you press something." Ignorance. "...realtime music apps is something else that doesn't exist on Android, because of the terrible latency." Ignorance.

Of course "seconds" doesn't apply to everything. I am a hyperbolic person, that's how I roll, but I can easily give an example of "seconds" which I recently saw, making that statement true. On the engadget video of a Kindle Fire some person repeatedly had to tap on the same icon multiple times to get it to register. That literally took seconds. That kind of non responsiveness is something that has never happened on my iPad.

As for the audio and music problem, can you link me to a realtime Android piano or guitar that actually works without any lag, like there is on iOS?

iOS is wonderful for music apps, thanks to core audio. core midi etc. I know a lot about music apps and use them often.

Would you like me to link you to developers on a music creation forum talking about how Android is problematic with music creation software, and where they explain why in great technical detail?

It seems that it is you who is ignorant of music creation apps on Android. There is currently a huge lag, making them unusable.
post #116 of 138
Quote:
Originally Posted by Neo42 View Post

Yeah it is not like modern (resistive or capacitive) touchscreen technology but the intended use is the same albeit issues with dirty sensors and poor resolution. My point is people need to stop acting like Apple created the touchscreen user interface in general. Too much credit goes to falsely implying Apple has invented technologies when the real strength lies in evolving old stale ideas and improving their function.

I completely agree that Apple gets undue credit for "inventing" things that they did not.
By taking their time to do things right and proper the first time they simply set a standard of excellence for existing technologies.

By the same token, Microsoft and Google did not invent the concept of ripping off other peoples work and then implementing poorly... they just set the standard.
post #117 of 138
Quote:
Originally Posted by Gon View Post

Unless you are trying to argue that Google is evil and therefore it is a good idea to make contentless shit-stirring posts on AI, I have no idea what you are going for.How about taking the real debate to its own thread, then? This one is about UI lag in Android.

Hmm...

Anyone into tech will instantly recognize I was talking about ui lag. Simply the real reason behind the issues instead of...

Well never mind. Seems Gon is gone and took its stupid flag waving for an ad company with them.

Rest of the comment thread was a lovely read.
you only have freedom in choice when you know you have no choice
Reply
you only have freedom in choice when you know you have no choice
Reply
post #118 of 138
Quote:
Originally Posted by AbsoluteDesignz View Post

2) reasons why Apple and Steve (who are usually litigious) decided to be functionally retarded in this case and allow it to happen without bringing evidence of such duplicitous action to court and pretty much ending Android with one move.

Oh, that one's easy and has been well covered for years now. Apple has elected to point its lawsuits at the targets where the money enters the system, i.e. at the hardware makers that sell the questionable products, as opposed to at the software maker that isn't really making any money from them (at least not directly). This is the right call from a litigious point of view.

Thompson
post #119 of 138
Quote:
Originally Posted by thompr View Post

Oh, that one's easy and has been well covered for years now. Apple has elected to point its lawsuits at the targets where the money enters the system, i.e. at the hardware makers that sell the questionable products, as opposed to at the software maker that isn't really making any money from them (at least not directly). This is the right call from a litigious point of view.

Thompson

So instead of presenting the evidence that so many Apple fanatics feel they've seen which shows that Schmidt double crossed Apple they elect to go after a few OEMs for a few IP infringement cases (most avoidable) to bring down Google?

So you too are saying Apple is stupid?

Shocking.
post #120 of 138
Quote:
Originally Posted by Gon View Post

In which ways does the Galaxy Nexus or the Galaxy S II lag so badly it makes the whole device suck?

I have brought up that issue in other threads involving the Galaxy S 2, in answer to the usual blind claim of "technical superiority" of the Galaxy S 2 over the iPhone 4S.

It is good that this article backs up exactly what I described based on using the device and provides an answer based on fundamental flaws with Android which I have noticed on every Android device I have used, going back to the HTC Magic.
A problem occurred with this webpage so it was reloaded.A problem occurred with this webpage so it was reloaded.A problem occurred with this webpage so it was reloaded.A problem occurred with this...
Reply
A problem occurred with this webpage so it was reloaded.A problem occurred with this webpage so it was reloaded.A problem occurred with this webpage so it was reloaded.A problem occurred with this...
Reply
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: iPhone
  • Former Google intern explains why UI lag occurs more often in Android than iOS
AppleInsider › Forums › Mobile › iPhone › Former Google intern explains why UI lag occurs more often in Android than iOS