Slashdot Mirror
The Android Lag Fix That Really Wasn't
jfruh writes "When Android was first introduced, it got much of its buzz in the open source community, and despite it being a mobile juggernaut backed by huge companies, it remains an open source project that anyone can submit code to. Thus, when a community patch that claimed to reduce the lag that still plagues the platform was created, it rocketed around various community code sites and was widely praised. The only problem: it didn't actually speed Android up."
I wasn't aware you could add code to the next release of Android? Where is the current nightly build?
If the problem is that they can't generate "random" number fast enough, maybe they could just return 42 when the entropy pool is empty.
Have you read my blog lately?
This is why "vortex" generators for carburetors are still sold http://www.vorteccyclone.com/ , Magnets for your fuel lines to "align the molecules" http://en.wikipedia.org/wiki/Fuel_saving_device are still sold, and oddly shaped bicycle cranks http://z-torque.com/ are still sold. Its really no surprise that it happens in the software world too. Really, its been happening for a long time. Regcure, anyone?
Nobodies Prefect
Tidbits for Techs Technology Blog
but sent using Android, so...
The butter project was about latency with user interaction. The issues talks about /dev/random, which is totally unrelated.
At least as a project leader, Linus tells people off when they go all hair-on-fire about some wingnut idea.
Apparently, the placebo effect also works to cure percieved computer ailments...
Ah yes. I guess that's why Google desperately launched Project Butter to make Android smoother and less laggy. 'cause it doesn't lag, right?
gSheeps. You gotta love them.
My Google Nexus tablet begs to differ with your assessment.
I've only been using Android since 2011 and my devices have never had any kind of lag. Maybe because I have Nexus devices that aren't encumbered by third party skins and interfaces.
The problem is that xda is full of this kind of crap. Kernels which disable fsync (libEAT-MY-DATA, anyone?), exotic I/O schedulers and CPU governors, overclocking processors and other hacks... Very often, they do not have any measurable effect, or even cause new problems, such as freezes, hangs, sleep of death,...
Slow phones are slow, fast ones are fast, and occasionally things stick on Android, but no more than on comparably priced hardware using "the other" platform. You know, the platform whose fanbois try to smear Android by placing stories about supposed fixes for supposed problems on Android.
Yeah, since Android 2.1 I haven't got any lag on my Android phones and I have used from 107€ to 370€ smartphones (those are retail prices without contract and CPU was from ARM6 600Mhz to 1.2Ghz ARM7 etc).
Only problem what was between 2.1 and 2.3 (2.1 & 2.2) was that it could take 1-2 seconds to cold start a application but then it was fast.
And now when I have upgraded to 4.1 (on 2.1 phone) I have got only more speed and more nice animations.
The results of "Project Butter" was noticeable when I scrolled lots of different animations on webpage, but problem was not a lag, but the frame drops what the project fixed.
Lag = non existed
Frame dropping = rare cases before 4.1
And? My google nexus tablet begs to differ with your assessment, you insensitive clod!
no really - mine runs quite smooth, even if battery life went to crap after the latest patch.
I believe I stated modern. I would have no problem to tell you if my Nexus 7 or HOX lag, but they don't... I'm sure you can dig up a case where they lag, but normaly, they are fluid.
The point of all such projects is purely PR. Google had to look like they were doing something about it.
PlusFive Slashdot reader for Android. Can post comments.
Which was not the source of the lag. The lag was endemic to Android itself.
Links coming up in Chrome from external apps are slow as heck. Once Chrome starts it's fine, but it just sits there. *Tap* 5-6 seconds, then Chrome.
Haven't noticed anything about battery life, although I had previously disabled Currents, which is the supposed cause.
Is http://www.downloadmoreram.com/
Remember these are the guys who cant even understand what their laptop AV software is reporting.
There are a lot of comments on the bug report page. Clearly this is not a dalvik bug since dalvik does not use the /dev/random. But the other commentatros are still unsure that there might not be some issue in how randomness is generated in android from user input, which might induce lag.
Right now, some folks still investigate.
Because you can't fix stupid.
Ok, it only works if you've got a cybernetic dolphin who can use SQUIDs to read you brain, but you could still become a very technical boy...
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I can only speak for the Galaxy Tab 2 7.0, but modern Android devices are faster in part because of software performance improvements. Android 4.1 and 4.2 both have performance improvements, and upgrading the Tab 2 from the 4.0 it came with to 4.1 or 4.2 makes the OS visibly faster. The Nexus 7 comes with Jelly Bean (can't recall if 4.1 or 4.2 out of the box), so everything is fast to begin with.
In this way, Android is similar to Mac OS X - initial releases were rather slow, and subsequent versions (10.1, 10.2, maybe 10.3) were faster simply because there was a lot of easy optimization work to be done.
As an iOS user I didn't really like Android until Jelly Bean.
>> "didn't actually speed Android up."
If you actually read the bug mentioned in the summary - most devs are arguing that explanations about why the fixes work don't make sense in terms of Dalvik (java) that the android bug was filed against - not that it doesn't improve latency or that it doesn't work or there isn't a lower level issue. One developer https://code.google.com/p/android/issues/detail?id=42265#c162 (sorry I don't know enough about android to know if he is part of the core team or not) - is doing testing to measure results of a patch from the mainline linux kernel https://patchwork.kernel.org/patch/1745611/ plus some re-arranging of the android code to see if he has found a lower level solution.
All touch devices have lag, including iOS, and it's significant. Anyone that's tried to draw using these devices knows this. Check this out: http://www.engadget.com/2012/03/10/microsoft-cuts-touchscreen-lag-to-1ms/
This looks like a real bug to me. /dev/random instead of /dev/urandom, which of course causes them to be unnecessarily slow.
The problem is that many apps use
A "hack" was to make /dev/random behave like /dev/urandom, but it's not clean, which is why it's not done in the official version.
This might be related to chrome.
Maybe you want to try firefox for android - it works quite well for me. If it turns out to be faster, it's still google's fault, but then you know the chrome guys are responsible, and not the android guys...
Having slogged through the linked discussion, there is no conclusion either way whether this effect is real or not. There are several theories on mechanisms that could cause an increase in responsiveness, but no conclusion. The most plausible seems to be that when the entropy pool is near empty, each input event causes a context switch as it is used to refill the entropy pool. Slower input handling obviously leads to poor responsiveness.
The summary seems to just be random android-bashing.
Slashdot - News for Nerds, Stuff that Matters, in ISO-8859-1 Has just realised that beta makes this signature redundant
If it didn't exist, then why the need to do something about it, or look like they were doing so?
Bad crypto can cause you no end of trouble. There are people out there who know what they're doing who've written PRNG systems in the general direction that you're talking about, but understand what to do and not do in the designs. Some of it's pretty subtle, like only bringing in new entropy in big chunks rather than trickling it in, and knowing what crypto algorithms work well for applications like this and what don't. And some of it's tuning.
Go read the "/dev/urandom" Wikipedia page. If you need Yarrow, use it.
The general speculation is that something in Android is using /dev/random when it would probably be ok with /dev/urandom, but nobody's sure quite what. Google Maps was mentioned; maybe it's using https to fetch map segments or something?
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Reading that bug report makes me incredibly glad that I've only worked on open source developer tools, if the comments on that bug report are typical I imagine Google must have high turn-over of developers on the project.
If you've used an apple device then an android device, you realize how slow android is. It's not terrible, but it greatly diminishes the user experience because the screen isn't glued to your finger.
I think confirmation bias can easily kick in in a situation where the problem is intermittent or hard to discern.
If the platform only sometimes lags, it is easy to take the non-lagging episodes when the system is functioning well as confirmation of the nonexistent fix, and write off the lagging episodes as remaining issues that are not yet addressed.
If the system had had consistently bad response to every event, then a non-fix would not be accepted so easily.
but modern Android devices are faster in part because of software performance improvements.
Historically you can always get more performance improvements out of software than hardware. Software improvements of 100x on bottlenecks are not uncommon (Google for example has made a ton of them in search, http, maps, etc). This is the same as running on hardware that is five or six generations in the future.
The classic quote is that primality testing has benefited more from better algorithms than from 40 years of Moore's law.
Bullshit fanboy.
Even the Nexus 7 lags. I'll buy that you don't' notice it, but it most certainly does. I've had and returned two Nexus 7s hoping to find the lag had been fixed, but it hasn't.
Part of the issue is the way apps are written rather than the OS at this point I think. The play store is a prime example of visible lag that exists due to a poor app design.
Scroll through the play store on a nexus 7 device quickly and it'll scroll fine then stop cold in its tracks, which a sliver at the bottom of the screen saying 'loading' or something to that effect. Technically its not lagging, but it sure as hell FEELS that way. The simple solution is to get a total count at the start, then calculate how far you can scroll total and not stop scrolling to display the loading screen, just scroll into blank space.
This scrolling into black space and loading later is what you'll find on Apple written apps for iOS and is why iOS doesn't get the same perception.
Yes, I'm an iOS fanboy, but I've TRIED to be a Android fan and I just can't do it. Put them side by side and the built in Apps on iOS will feel far better than those built into Android. Actual performance is irrelevant. How they feel matters.
The only people I know that say Android isn't laggy are people who don't use iOS devices. If you have nothing to compare with, you just don't notice.
Yes, 4.1 is smoother than 4.0, Yes, 4.2 is smoother than 4.1. But the apps need worked now that the OS isn't as bad as it once was. I've seen Android apps that don't lag, but the default ones due. Chrome has the same sort of shitty lag when scrolling, where mobile Safari doesn't.
Perception is far more important than reality when it comes to user interface. Another thing as an iOS user that makes Android 'feel' laggy is the lack of rubber banding on scroll. Yes, the Nexus 7 has the blue glowy thing when you try to scroll past the end, but again as an iOS user, it feels like lag to me as the blue glowy isn't all that noticeable compared to the rubber banding. Yes, I understand Android previously couldnt' do rubber banding due to patent issues, but my point is that while Android may not ACTUALLY be laggy, it still is perceived as such due to the UI.
You can deny the perception, but it doesn't change it to most people and it will certainly remain one of those things that you're going to hear from iOS users until it changes.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Or you just don't notice it.
I find that anyone used to an iOS device can pick up a Nexus 7 and notice the lag.
If all you use is Android devices, you probably don't notice.
Its not actual lag so much as poor UI choices that are perceived as lag at this point in my opinion, but I most certainly can 'feel' the lag.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Possibly. I never had a 'nexus', just the basic Samsung stuff. One problem that I noticed is when running 'drum kit' apps. I have tried some on my Android phone and several on my iPad (1st generation). On the iPad the drums react almost instantaneously. On the androids there's a noticable (and fatal) delay.
Did you ever try anything like that on you nexuses?
I have a Galaxy Nexus and I notice the lag mostly when browsing the web.
Apparently the OP didn't read the thread he alleges disproves the performance increase. There is actually a very lively discussion going on about it, and while there's a general agreement that it's not as simple as the /dev/random pool getting depleted, there is some evidence that it is related to locking in the UI (see comment 162).
Especially when there can be situations where if someone taxes an iPhone enough it'll show occasional stutters or quirks as well, especially when using third party applications. It's a comparison to a nonexistent ideal that is assumed to be true of iOS, and is all the more noticeable when using a past-gen iDevice using the more modern OS versions. My 4 lags regularly even within Apple's in-house crafted applications. Jelly Bean on older hardware is, shocker, the same way. There's optimizations which can be made but there'll almost certainly always be examples of lag or stuttering or UI quirks on any platform.
Typical uneducated dumbdroid. Don't even know what he/she is using.
I like to try drum kit apps ( I have kids ). But on my Android phone there's a perceivable (and intolerable) lag when you tap the drums with all the apps I tried. On iOS (1st gen iPad) they're all nearly instantaneous.
Ever try anything like that?
Don't get me wrong, I'm not an Apple fan, I'd like Android to win, but not by closing my eyes for its faults.
http://finance.yahoo.com/news/southwest-orders-more-mileage-stretching-222419202.html
Interesting research, seemingly terrible reporting by Engadget. Seems to me that MS did not "[cut] touchscreen lag to 1ms", they simply demonstrated via a test device (which appears to be projecting light from above) what different amounts of lag look / feel like.
They have to address all the trolls.
Otherwise they look like they don't give a damn about the end user. Most companies in a free market have to wory about that sort of thing. (pissing off customers)
A Pirate and a Puritan look the same on a balance sheet.
> I find that anyone used to an iOS device can pick up a Nexus 7 and notice the lag.
I find that you're full of shit. We're people that were used to PhoneOS devices and then defected to Android devices. I was actually a little surprised how quickly the non-geek iFan in the household took to Android.
I figured that "ecosystem" would at least hold her back.
"lag" has never been an issue.
A Pirate and a Puritan look the same on a balance sheet.
A lot of people (like me) would say you are wrong about the Nexus 7. Once we got 4.2.1, they got slow and laggy again. Supposedly there is a fix in the works. But there are lots of threads on it - so it is not just an anecdote. Here's a link to one of the bug reports with a little over 100 people saying they have it too: http://code.google.com/p/android/issues/detail?id=39737. So something is causing that. I've actually been dismayed by how slow my 32 GB Nexus 7 got after the latest updates. I still like the device a lot, but it can be frustrating sometimes waiting for the screen to draw or waiting to turn a page when reading a book on it.
You are correct - however, I'm not sure if it's android issue of a hardware issue. I remember something like windows doesn't have any 0lag drivers, but linux did, but yiou had to use jax or something, not alsa. OSX has 0 latency and is great for musicians.
I wish someone else will come in here and state something like: yes, its software, lets build a new kernal for your android phone, or no its the hardware, buy this phone over here, it has no latency.
There are basically four things that make Android laggy. The good news is that most of them can be overcome by user-modified firmware. The bad news is that manufacturers and Google are unlikely to ever fix them directly, because it would increase the manufacturing cost of phones by a few cents.
ONE: KILL-VS-SWAP
Android's normal behaviour is to aggressively kill activities and suspended background tasks, then respawn them from scratch when brought back into the foreground or reactivated. The LINUX (and Windows) norm is to simply quit giving them CPU cycles, stash their state into swap space on the hard drive, and resurrect them later.
One reason why this is done is because Android devices, while not necessarily STARVING for flash, don't have it in quite the abundance that a normal computer has hard drive space. There are also concerns about prematurely wearing out flash. The problem is that flash rewrite life estimates are based upon general use of the entire block of memory... but a swap partition gets created in a specific chunk of flash, and that one tiny chunk gets relentlessly hammered. If your erase-rewrite activity gets spread across the whole flash, it would usually take months of active efforts to be destructive before you really caused damage. However, if you create a 256mb swap partition and hammer it relentlessly, you can permanently damage it in a weekend. For this reason, few at XDA will advocate ever using internal flash for swap.
That brings up catch #2... if you swap to microSD (because it's cheaply replaceable should you end up damaging it), you really need class 6 or better. Swapping to class 2 flash will leave you running more slowly than if you left Android to its default behavior. Guess what class of flash invariably comes with the free microSD card shipped with the phone? Class 2.
Making matters worse, the users in the best position to experiment with swap enhancements are Nexus owners. Unfortunately, Google has this near-religious aversion to microSD, and I don't think any Nexus device since the original Nexus One has shipped with a microSD slot. All that said, if you have a rooted and reflashed Android phone with class 6-10 microSD that has a swap partition and a custom ROM that uses it, you MIGHT see a big reduction in lag if you frequently run apps that have "expensive" startup costs (ie, apps that always begin by trying to make a http request to somewhere, or generate cryptographically-secure random numbers, etc).
TWO: DISDAIN FOR 2D GPU ACCELERATION
Historically, Android hasn't done a good job of putting 2D acceleration to good use ICS was a step forward, but you can't help but feel like the GPU support is more symbolic, half-assed, and buried under 400 abstraction layers that fritter away most of its potential. At least, for simple and straightforward "scroll and/or pan the viewport across a large virtual bitmap" type operations.
Compounding the problem is Android's architectural bias towards generating content on the fly, instead of generating humongous virtual bitmaps and keeping them available for instant viewport rendering.
THREE: ANDROID'S MEMORY-MANAGEMENT SUCKS
Building upon 2, and being completely blunt... Dalvik's memory-management totally fucking sucks compared to Java's. ESPECIALLY the way it handles short-lived objects that get repeatedly created in large numbers, and discarded almost immediately.
I dare anyone to disagree. Half the Android API bends over backwards to tiptoe around Android's shitty heap-management by trying to avoid creating and discarding objects for use as short-lived containers.
No, don't give me crap about mobile devices having limited resources compared to desktop computers. That's bullshit, and everyone knows it. Java mostly solved the worst of its memory-management problems around 1.5. Compare the specs of a high-end laptop circa ~2002 with the specs of a Galaxy S3, and arguments about Android devices being "severely resource limited" just kind of fall on the ground and thrash aroun
I find opera the fastest but I miss my desktop sync
We've got an iPad 3 and every pdf app is intolerably slow at rendering to the extent that I have almost entirely written it off as a computing device.
It will clearly be several generations before tablets are a practical replacement for a laptop.
Trust The Computer, The Computer is your friend.
Never noticed it myself. Runs smooth as butter.
Untrue. Modern Java (since 1.6, if not earlier) has nearly native performance on most platforms.
Android's "Java" problems are specific to DalvikVM inferior heap management strategy. Java 1.5 and newer does a VERY good job of dealing with mountains of short-lived objects that get promiscuously created, then discarded almost immediately. DalvikVM falls flat on its face, and ends up stalling to do garbage-collection.
Part of the blame lies with Android's strong (if not overwhelming) architectural preference for destroying and restarting activities, vs suspending them to swap. The truth is, Android handles long-lived processes VERY poorly... partly, because its preference for kill-and-relaunch has allowed them to sidestep the larger issue of managing resources with long-lived processes for several years now. That's the REAL reason why Gingerbread began actively killing even well-behaved background services that were running for "too long". Metaphorically, they were like a little old lady with a nice, neat house right smack in the middle of an urban block some developer wanted to bulldoze and redevelop with a skyscraper.
Sun had to grapple with the problem directly and solve it properly. When you have something like a web server written in Java that needs to be able to run for months without restarting, you MUST be able to hunt down insidious resource leaks, and keep them under control in the long term without being too disruptive at any moment in time. In contrast, Dalvik just ignores them until it runs out of space, then halts everything while it does garbage collection and moves things around.
This is actually one of the problems people who've experimented with adding support for swapfiles to Android have encountered. In order to make Android swap instead of kill, you have to modify its default behavior. The problem is, when you allow your Activities to live for hours or days instead of minutes, problems due to resource leaks that wouldn't get bad enough to notice start to become visible. As a practical matter, an Android phone with swapfiles forcibly enabled has to be rebooted at least once or twice a day, or the phone will start hanging to do garbage collection more and more often (defeating the point of having the swapfile in the first place).
Lazy Googling on my part -- I just pasted the first link to the thing I found. I think I originally can across this in a podcast.
It might have to do with the audio lag in the android sound system. Android uses something called audioflinger which had a very high latency. This became apparent to me when I tried running some emulators on my phone a year ago. Android 4.1 (Jelly Bean) seems to have fixed this issue http://www.youtube.com/watch?v=1WQcl4RDl5I
Having spent significant time with iOS devices, I can safely say that the notion that they do not lag is FALSE. Having just installed iOS 6 on an iPhone 4, the lag between just opening and closing basic applications is definitely noticeable. Hell, even my father's iPad 2 lags, and it runs on iOS 4!
My S2 Skyrocket, on the other hand, runs Jellybean 4.1.2 just fine, and cases of lag are rare, if any.
The fact is, all devices, get laggy with use, and your bias against Android makes you ignore the lag that the shiny animations of iOS induce.
There is no perfect, lag-free device.
I have a Nexus 7 and an iPad Mini.
The Nexus UI is pretty smooth and generally responsive, sure. But the iPad's animations are almost always smoother and input lag is non existent. If I didn't use both I'd probably think the Nexus was good, but really it's just OK and for some things the input lag borders on intolerable.
We're currently finishing up a fairly simple music app for Android with a couple of fun features.
In the beginning we were fussing around a lot with the Android UI and Audio APIs, as the lag when a user pressed a button widget until audio was played was very noticeable, we couldn't get rid of it. After hitting a brick wall we simply started from scratch using only a blank canvas, manually drawing buttons and handling events and the like and things worked perfectly.
So I the lag we (and probably everyone else) experiences has little to do with Dalvik but everything to do with the Android UI widget event handling, it causes unresponsive UIs.
I never noticed it before but now I see it all over the place. The only apps that don't have it are games and apps like ours who sidestep most of the Android Widget/Event API and go the manual route.
This sig is intentionally left blank
I care not for your add Eminem atacks.
My Nexus 7 used to be great until Android 4.2. It's very slow now.
Android does save Activity state, it's lifecycle 101. Just look at the onCreate method signature. What do you think "savedInstanceState" means?
@Override
public void onCreate(Bundle savedInstanceState)
Expect everyone to acuse Apple 'fanbois' of making this up. How dare they insult the latest korean superphones!!!!1
You can't have 0 latency audio drivers. But the latency can vary from system to system due to design decisions.
The main source of latency in audio drivers is related on how many audio samples are generated for each call to the interrupt handler (buffer size).
Bigger buffer sizes help avoid gaps in audio due to interrupt jitter. They also reduce the CPU load and energy usage which are very important in mobile devices.
Driver infrastructer for very small buffer sizes need to be designed very carfully to work reliably. So there are many reasons why android developers decided not
to use very small buffer. BUT of course for any kind of interactive audio low latency is crucial.
That's a chrome issue. Chrome in 4.2 is crap. Switch to Dolphin Jetpack and it's much faster.
"Native performance" in benchmarks is not the same as "fast smooth responding" software.
It seems like on Android, the less you rely on built-in libraries/APIs the better your app will be.
Which is the opposite of how things tend to go with iOS development.
I am using G-stomper, sometimes on a SGS1 with Gingerbread, all bells and whistles enabled, and I have rarely seen lags, except when Tasker fires something in the background.
Haven't used any other drum kits or machines, so can't really comment on those, but if one can get it right ...
And where do you think Android lag problem comes from?
Pretty much. Neckbeard rage will ensue.
> Even the Nexus 7 lags.
> Technically its not lagging, but it sure as hell FEELS that way.
Wow. How is this post rated 5?
When a user clicks (touches, slides, speaks, whatever) an object in the interface, the expectation is that the response will be immediate. Leaving aside communications delays, which users largely understand they have to live with, there is nowadays no excuse whatsoever for the device failing to respond instantly, even if only to provide feedback that acknowledges the interaction (for example when it involves an operation that is known to take measurable time such as opening an image file).
But the OS's own processes are regarded as sacrosanct, so the user interface just has to wait until they condescend to allow the user a few of their precious cycles. This happens on all end-user systems running multiple processes (leave IBM mainframes out of this :-) — just look at the time it takes to get a response from the Unity Dash, or the Gnome menu button, or the Windows Start button (or whatever it's called this week), or the Mac menu button...the first time you click it. It sits there loading its menus. Finally it lets you see them. You run your application, and for a short while, another click on the dash/start/menu will get a fairly swift response. Leave it a little longer, and it's been swapped out and takes another age to reload.
Developers, achitects, engineers, and programmers need to grasp the fact that their background processes must take a back seat when the user wants to do something. Their reply, quite naturally, is that their background processes are vital, essential, cannot be delayed or interrupted, etc etc. And quite right, some of them are. But it's their job to see to it that they are written and scheduled in such a way as not to interfere with the interface. Anything else is a design failure.
Lag is in the time it takes between a user pressing a UI widget and the time it takes the OS (or app) to react to it.
For example, in Android when you scroll the lag is very visible. Your finger is half way into the screen by the time Android reacts. That issue is not that highly visible in ANY other mobile OS.
I'm going to be honest, but I'll probably be modded into oblivion, and/or called a shill.
I bought a Nexus 7 because I wanted a tablet, I didn't want to spend $329 on an iPad mini, and Jelly Bean was supposed to fix the lag issues. I wound up returning it for a variety of reasons, but one of them was that the UI performance felt about on-par with a first-generation iPad (which I also sold, though for different reasons). I really wanted to like it. For all I know as someone who doesn't use Android, Jelly Bean is a massive improvement in this area. For all of the things Android does well, its UI performance and subjective responsiveness are still not on the level of iOS.
If you can't convince them, convict them.
Probably because the mods read the entire post in context.
If you can't convince them, convict them.
Can I root for no one to win, but for it to remain a stalemate with several competitors?
Or do we all need to wave the flag for one uncaring corporate juggernaut or another?
(Also, do we have to present credentials like this with every opinion we post? Would the validity of your opinion change if you were an Apple fan? Are we reddit?)
I think we all know you get what you pay for.
Views expressed do not necessarily reflect those of the author.
You do understand, don't you, that the reason the user interface has to wait isn't because developers think our processes are more important than the users.... but because the user interface DEPENDS ON THOSE PROCESSES TO BE ABLE TO DISPLAY!
Car analogy: You're complaining the the engine management computer insists on doing its fuel map calculations before responding to the throttle.
it'll scroll fine then stop cold in its tracks, which a sliver at the bottom of the screen saying 'loading' or something to that effect.
Me thinks its better to tell the user whats happening and only someone extremely biased or entrenched to how Apple does things would call this lagging..
Put them side by side and the built in Apps on iOS will feel far better than those built into Android.
You mean like Apple Maps?
Another thing as an iOS user that makes Android 'feel' laggy is the lack of rubber banding on scroll.
You mean the 'feature' over which Apple was suing Android handset makers? Yup thats a real bright idea.
The time between clicking an app and it appearing on your screen is not lag. That is just the OS being a little slow. Lag is scrolling on the screen and having the graphics catch up with your finger. It's there and it has been perceptible on every Android phone I have used.
I have a G2. Not rooted or anything. Most of the time it's fine. Every so often, when I touch keypad buttons during a call, Nothiing Happens. A few seconds later, any and all buttons I've hit will play back very very fast.
It really is quite noticeable.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
I think you overstate your case. When I click the Windows Start button on XP it does respond. What I want of course must wait for the data to be available and rendered, but at least the Start button appears in a different state than prior to clicking. It gives me reason to believe the computer has acknowledged my action and will respond.
Often my interactions on my Android phone take time to give me any response. That is a failure and any app should work diligently to fix it as I am happy to use a different app. My phone is not a person, I do deserve to lord over it.
Who is the bigot? You're the one spouting ad hominems. Perhaps the GP is opposed to Apple's shiny walled garden? Perhaps he is pro Freedom? I would submit that it's Apple Fanbois like yourself that are the real bigots.
Have not seen this problem, but I have a problem with external mouse not scrolling. It's a registered bug in the database, closed, with a patch - but I have no idea what that means or when/if Samsung will roll that out - ha!
I think therefore I can't be ~TTNH
Linux can provide realtime (guaranteed latency - zero latency doens't exist on a Von Neumann machine) services (hard realtime even with a proper microkernel) but the issues Android has aren't general to linux driver latency, they're special Android issues.
And boy would I like to see them get cleaned up! Google must have profilers...
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Its UI performance and subjective responsiveness are still not on the level of iOS as iOS was 3 years ago.
My old iPhone 3G is more touch-responsive than my Galaxy Note.
I have nothing against Apple perse, but I have serious issues with the closed nature of their iOS devices and especially how I don't have the ability to control what gets transfered on or off the device. Everything has to go through iTunes or some cloud solution.
Android has no such restricting policies, that's why I'd like to see it 'win'.
Perhaps you type slow. I frequently get out ahead of the display by a word or two and have to sit and wait for the display to catch up with what I'm typing. Another annoying feature is clicking something and it has no effect, so you click it again only to find out that the first click went and now your second click was on something that wasn't even displayed at the time. Every damn hour. Galaxy Nexus.
No opinion lives in a void. Knowing that someone uses a particular device or not, or even if they are preferential to a company or not, gives important information that should not have to be gleaned from an opinion. And no, you don't have to root for a team, but what's the fun in watching? Seeing some good fundamentals? Ok, we are nerds, that is a great reason to watch!
Fast UI response requires multi-threading. There are many reasons that programmers are not implement it more often, but Java added one more: GC, which usually stops the world when it collects. Also programmers who replie on GC are often unable to plan resource usage very well, a skill crucial to multi-threading.
Not necessarily a bad thing though. On windows you can build very bloated applications using many libraries but you can also build http://news.slashdot.org/story/13/01/12/1332204/the-android-lag-fix-that-really-wasnt#state of the art stuff going low level yourself.
You have no idea what a mutex is, do you?
hmmm, how did the link get in there?
Why leave mainframe out of this? Mainframe's amaizing ability to stay perfectly responsive even at 100% CPU utilization, while it is runnig multiple and dissimilar heavy workloads (which inludes a LOT of java processing nowdays) should make some people at least look at it's workload management concepts and solutions.
I sincerely hope that nobody will "win". I'd like to continue to see some choice and competition.
Exactly this, I don't know why GP or GGP were modded down. Basically, when accused of some vague problem that is hard to determine, you have two options:
- say "You're holding it wrong" and do nothing about it
- say "Ok people, you are right, but we fixed it" and again do (almost) nothing about it
Google went with the second option. Yes, they probably made some small changes, but considering rapid advances in hardware, spending major resources just for removing small delays is a bad decision.
PlusFive Slashdot reader for Android. Can post comments.
Uses AES. You can perturb it by writing "entropy" to the device to reseed it, but obvious it never runs out like the Linux /dev/random.
4.1.2 was amazing!!! 4.2 screwed everything up on my galaxy nexus. Nexus 7 is less effected. Basically the amazing jump in speed when project butter was released was effectively undone in the 4.2 update.
how do you manage the audio glitches when the garbage collector is run?
It's incredible. An ARM running at 1.6GHz with half a gig of mem and it can't play an mp3 without glitches.
Looking for people to chat about multicopters, coding, music. skype: gtsiros
I agree with you. The real issue is that a PC has a much narrower bus to move all of that data around. You can throw all the cores in the world in one box, and something like a modern mainframe will still stomp it because it is so much more massively parallel.
zosxavius photography
Have you ever used OS/2? Under a full load, even constantly swapping, it would be very responsive. Rarely did the UI feel like it was lagging. Compare to my windows 7 laptop. Under massive swap or a heavy load sometimes it takes ages just to get the interface to respond so I can switch a task or dial down priority and make the system usable again. That I have to manually turn down the priority of applications that slow my system to a crawl so other tasks can run says a lot about how much windows fails on multitasking compared to better operating systems. I like windows 7, but when I think back to OS/2, I still yearn for something that is as responsive.
zosxavius photography
That's not a good analogy; almost everybody would complain if those calculations were slow, but car companies spend tons of time and resources making sure that the throttle response is as quick as possible.
Also, I disagree with your statement; I think it would be true if you were talking about booting up the computer, but once things are showing, the computer doesn't really need most services or processes to display things to the user; responding to a user action could be instantaneous is almost all circumstances, but the problem is partly that the GUI will wait for the information synchronously (instead of showing some reaction and then load the data once it's ready), loading everything before starting to render the results, and also resource starvation due to low priority of the UI part (specially when running other things in the background, or when booting up).
Speed Dial for Firefox
It's exactly the same on the Nexus S.
it's definitely an issue my on my galaxy s3 and on my old galaxy s1. as a music producer I would give my firstborn to see this fixed
You do understand, don't you, that the reason the user interface has to wait isn't because developers think our processes are more important than the users.... but because the user interface DEPENDS ON THOSE PROCESSES TO BE ABLE TO DISPLAY!
Where there are systems where that is true, then that only confirms his point. There should be nothing holding up the UI between a user interaction and the display of some feedback to that interaction. Whatever processes are necessary to that should be loaded at startup, never unloaded, and never have a delay of more than a single video frame. 8 bit computers could provide instant feedback to any user interaction. What went wrong?
Funny. Mine works just fine. Perhaps idiot users installing a bajillion apps are the problem, rather than the OS or device.
"lag" has never been an issue.
So the discussion here is based on nothing, everyone reporting differences here is wrong, and all the people discussing lag here are wrong and that project butter was completely unnecessary and does nothing and google are lying because "Android lag" is just one huge conspiracy? Blind fanboys are one thing, but idiots like you are in such denial you take it to a whole new level of ridiculousness.
Meanwhile the old classic MacOS systems would stop the world whenever you held the mouse down. Have a BBS running in the background? Watch the modem literally stop blinking just because you're holding down the mouse button.
Could be done, "by design"
- as Microsoft likes to point at bug reports that will not be fixed
- as BeOS / Haiku developers did in their "lag free" os
Or you just don't notice it.
I find that anyone used to an iOS device can pick up a Nexus 7 and notice the lag.
If all you use is Android devices, you probably don't notice.
I found the opposite.
I only used Android up until work made me carry an Iphone 1 week out of every 4. Found that IOS was so slow compared to Android 2.3 (Gingerbread) but they just covered it up by using animations. It too longer to open the messaging application on IOS than on Android.
I timed them side by side, Android was much faster to open the application. The phones in question were an Iphone 3GS and a Motorola Milestone (Moto Droid) so they had fairly similar specs. This was on IOS version 3, when we updated to IOS 4 it slowed down horribly.
I tried it again recently comparing an Iphone 4GS to my (Samsung) Galaxy Nexus, there was an even bigger gap between Android 4.2 and IOS 4 (the owner hadn't updated to IOS 5 yet)
but I most certainly can 'feel' the lag.
Here's the problem. You "felt" it, you didn't test it. I actually tested it.
If you get lag on a Nexus device, you're almost certainly imagining it.
Now beyond this, I find IOS far more infuriating to use as it forces me back to the home screen every time I want to use another application where as Android has rapid task switching, not to mention the lack to text reflow. Even if Android lag was as bad as you said (and having run some really bad community ROMs on my Milestone and Desire Z, I've seen bad lag) it would not slow me down anywhere near as much as IOS is _designed_ to slow me down.
Calling someone a "hater" only means you can not rationally rebut their argument.
There's nothing in his post to suggest he doesn't.
I was responding to the assinine notion that there can't be a satisfied Android user.
Some people just can't handle a satsified customer using something other than their own pet brand.
YOU are just that kind of idiot.
The same goes for any of you other MORONS that modded down my original response as "flamebait". A contrary opinion or experience is not flamebait.
Also, the idea that Android "problems" are any more consistent than Android itself should seem absurd to anyone with any functioning brain cells. That whole dreaded "fragmentation" thing works both ways.
A Pirate and a Puritan look the same on a balance sheet.
I actually tested it.
Then show us the test results.
If you get lag on a Nexus device, you're almost certainly imagining it.
Wrong.
The time between tapping a key on the virtual keypad and the character appearing is and I've seen that often enough on an iPad1 running both iOS 4 and 5.
That's an interesting assertion, considering that we were using the MR primality test for 30 years.
I was responding to the assinine notion that there can't be a satisfied Android user.
Some people just can't handle a satsified customer using something other than their own pet brand.
Nobody said that you fool, you're so blinded by your apologist views that you're imagining a situation where everybody is against you where clearly no such situation exists. There are plenty of satisfied Android users, lag isn't the be-all and end-all of user satisfaction but denying the existence of it on Android when it clearly does exist and clearly is a problem is just outing yourself as an apologist and fanboy when there is no need to be either.
Apple has a similar problem with input lag but it often manifests itself when upgrading a ~2 generations-old device to the latest version of the operating system, iOS is hardly devoid of this problem either, it's just it only appears on older devices.
the shiny animations of iOS
They're not shiny, they're smooth, which is far better than the jerky transition you get in a lag situation on Android. Yes both platforms have lag, iOS just handles it better.
Car analogy: You're complaining the the engine management computer insists on doing its fuel map calculations before responding to the throttle.
No. Not at all. What he is saying (at least what I think he is saying) is the ECU is insisting on checking the electric signal to the headlights, verifying that the DRM for the disc in the in-dash entertainment system is functioning correctly, and verifying that the brakes are still working, before it can bother to respond to the silly user input of pushing the throttle.
Having brakes that work is important. Having headlights that work is important. Having DRM that works is important (to someone anyways)... however, none of that is important (even the brakes!) in relation to pushing the throttle. Just fucking accelerate damnit. Seriously.
"Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen
Can I root for no one to win, but for it to remain a stalemate with several competitors?
Or do we all need to wave the flag for one uncaring corporate juggernaut or another?
No.no.no
If you want to wave a flag, you're talking semaphore, something like the kinect.
This is touch.
Defining Statistics and Social Research
While that was a very nice argument, and even a legitimate hypothesis of what's going on, there's no corroboration to what is actually happening, so take this with a grain of salt if you start discussing this at your local watercooler. It sounds authoritative though, so you might get away with it if you have stupid colleagues.
...I find IOS far more infuriating to use as it forces me back to the home screen every time I want to use another application where as Android has rapid task switching...
Does it really take that long? My Android phone lacks the dedicated task-switch-menu button so I have to hold the home button for 1 second to bring up recent apps. Even clocking in at a mere 1 second, it's still slower than double-taping the home button on an iOS device. Even if your Android device has the dedicated button, I think complaining about such trivialities is just that--complaining about trivialities.
I'd vote you if I had mod points.
I completely agree with you. Apple software and hardware is great, and I have nothing against them in principle but...the way they try to control the user is horrible and the artificial limitations they impose on their hardware for business reasons is irritating.
Let's not kid ourselves, Google is no saint, they are a corporation too seeking their own benefit but their software is more open and that's why I want them to grow.
The ideal situation would be that there wouldn't be a dominant player so that the smartphone companies would have to give the users what they want. Monopolies are bad for the consumer. Always
Root for each maintaining their separate Linux environments then using QtQuick as their standard. It's something most are trying. That way with any corporate result, users win.
Science & open-source build trust from peer review. Learn systems you can trust.
Nobody said that you fool, you're so blinded by your apologist views that you're imagining a situation where everybody is against you where clearly no such situation exists. There are plenty of satisfied Android users, lag isn't the be-all and end-all of user satisfaction but denying the existence of it on Android when it clearly does exist and clearly is a problem is just outing yourself as an apologist and fanboy when there is no need to be either.
He's not so much an Android fanboy as he's an anti-Apple fanboy. FYI, "jedidiah" has been around on the web and Usenet for decades, reacting angrily whenever anyone says even the most mildly positive thing about Apple or Apple products.
absolute fud. the ipad halts up often enough. i've used one and it aint a perfect daisy. you're seeing it through rose colored shades son.
Funny. Anecdotal evidence is hilarious that way. My 3G would crash, freeze, lag, and not respond most of the time. I switched to android specifically because of how bad the responsiveness on the 3G was. Never looked back.