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."
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.
Apparently, the placebo effect also works to cure percieved computer ailments...
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,...
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.
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.
Here you go: http://download.cyanogenmod.org/?type=nightly .
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...
hurr durr, yes this is all an Apple 'fanboi' conspiracy.
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
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.
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?
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.
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.
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.
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
Here's another http://replicant.us/
The lag was always obvious all the way up until ICS, where they introduced proper hardware acceleration for the UI (i.e. actually using triangles to render UI elements), however it was still not quite as good as it was on other platforms, they addressed this on Jelly Bean and the difference is pretty obvious to anyone who's used the same device on both versions.
http://www.youtube.com/watch?v=V5E5revikUU
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.
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
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.
There is indeed a plethora of android devices making them difficult to compare meaningfully. http://en.wikipedia.org/wiki/Comparison_of_Android_devices
> Android does save Activity state, it's lifecycle 101. Just look at the onCreate method signature. What do you think "savedInstanceState" means?
Yes, it does save its state. But after roughly 30 minutes, Android will become increasingly determined to kill it off at the slightest pretense and first possible opportunity. It's kind of like Windows and virtual memory... you can have 16 gigs, with 13 free, and Windows will STILL swap stuff out to virtual memory. Likewise, you can have plenty of free ram on your phone, and an app with a relatively small footprint, but after roughly 30 minutes, Android wants it dead & gone (even if it means relaunching it from scratch 2 seconds later) so it can scrub the heap clean and reclaim its space RIGHT NOW.
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 ...
Pretty much. Neckbeard rage will ensue.
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.
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?)
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.
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.
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'.
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?
Actually, when you have just a a couple of apps open at the same time on a iPod Touch on iOS4, say Safari and a game in, say Temple Run in the background, I notice significant lag when Safari renders webpages. In fact, even when I don't have any any other app open, just a couple of heavy pages, Safari lags. A lot. I take good care of my device, and ensure that memory usage isn't high by clearin RAM through SbSettings. Scrolling the through the song list on the music player on a touch is certainly laggy when you have 1000+ songs. I have experienced lag firsthand on iOS devices, and on poorly designed Android devices. As I said, there is no perfect OS. iOS devices, by virtue of their powerful GPUs, make iOS feel smooth, but when the system is strained just a little, you do notice the lag.
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.
You have no fucking idea what you're talking about do you?
>Android will become increasingly determined to kill it off at the slightest pretense and first possible opportunity.
What the fuck is the "slightest pretense"? You don't know what the criteria is for an app to be killed do you? Do you realize that Activities are all destroyed as soon as they go into the background? This is the NORMAL behavior. Android saves a marshaled Bundle of instance data when onDestroy() is called. At first this is stored in RAM, then the bundle is written to disk. Eventually the bundle is discarded if the user has not used that app for a long period of time.
Uhhh...since when does having a non mainline spin off count as being "open to user additions"? Has the world suddenly gone crazy or is this just another "We let them get away with it because they are Google and said 'do no evil' which we totally bought" kinda thing? That would be like saying "Oh anybody can contribute to Solaris, here is Open Indiana!"...well does the mainline users get their code from Open Indiana? No. Does the mainline branch take all their code from Open Indiana, like how Red Hat uses Fedora as a testing ground? No. Well then they ain't contributing to the mainline project are they?
ACs don't waste your time replying, your posts are never seen by me.
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.
since when does having a non mainline spin off count as being "open to user additions"?
There's no requirement for an open source project to be open to "user additions".
When was the last time you added something to the Linux kernel? Maybe you did, but that process is tightly controlled by the kernel maintainers.
Same thing for Firefox.
You are free to fork Android, like CM did, and make your additions there. Or fork CM.
I'm not saying Android couldn't be more open. But it's understandable that Google tries to keep control so they won't get sabotaged by Apple, Microsoft and others.
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
Butter only works if it has been ported to your device; many devices have had JB ported without enabling butter, especially those with proprietary graphics drivers. Depending on the spec of your device and the way you use it, you may not see any improvement even if it is enabled, and possibly even a degradation (as with any double buffering, the CPU ends up doing more work overall).
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 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
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.
A statement for which you have no evidence. But you say it hoping it's true.
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?
No, I say it based on my iPod and my Galaxy S3.
"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.
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.
That's an interesting assertion, considering that we were using the MR primality test for 30 years.
Then you had NO RIGHT to bitch about Open Office or Java or anything else that tells you to piss off when it comes to user contributions, after all you have the source so you can just fork it!
Why do you assume I did? It sounds like you desperately want to prove your point.
If you seriously want to add code to mainstream Android, feel free to follow the procedure:
http://source.android.com/source/submit-patches.html .
Did not read before posting, did you? if you had you would have seen I said quite clearly it was NOT directed at you but the blatant hypocrisy of the FOSSie faction. MSFT locks the OS through UEFI? "ZOMFG where is antitrust? Whargarbl!" Google locks THEIR OS with UEFI? /crickets chirping/
If I felt like bothering Slashdot has carried articles of Oracle and Sun doing THE EXACT SAME SHIT and the threads was FULL of FOSSIes having a royal shitfit, Google? The FOSSies trip all over themselves to apologize like a battered wife, "he don't mean it, he's just going through a bad time".
Nothing I hate more than a God Damned hypocrite and I hate to fucking say it since I really do loathe the man but this is one place where I give RMS credit, he has NEVER waffled and he pointed out when Google was being a douche just as he pointed to Apple and MSFT when they were being douches, its too bad that even St. iGNUcious can't get the FOSSies to quit fawning over Google like a bunch of 14 year old girls over Justin Bieber.
ACs don't waste your time replying, your posts are never seen by me.
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'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.