linux patch that MASSIVELY improves smoothness - Galaxy S I9000 General

http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1
This is a 200 line patch that according to linux was according to Linus the most impressive result of code that is elegant - 200 lines long - and should be wound into the phone linux as well
---- edit - and here is why it isnt going to be of any use for us...
http://forum.xda-developers.com/showthread.php?t=822756&page=210
and the meat of it from bilboa1 :-
Originally Posted by giulio.alfano
Have you seen these? w_w_w.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1
Phoronix(and Linus) say that is a miraculous 200 lines patch to increase interactivty? Can you consider the inclusion, of course if group scheduling in android 2.6.32 kernel is compatible?
the process groups are created per tty, that wont work on android
you can create process groups by hand however but it doesn't make a lot of sense for android in that case. the goal is to have some intensive tasks into their own group, but theres no intensive tasks and we don't have issues like audio or video lagging
their tweak is especially good if you run a compilation in the background and want to browse the web while waiting without having slow downs.
on android if you browse the web you dont have other cpu heavy tasks in progress usually (like encoding a video or what not)
i hope that was clear enough

I've off works urlaub would bei awesome
Where are the developers, who can say, if it works?
Sent from my GT-I9000 using my Brain

Wouldnt get too excited,phoronix is like the sun of linux news
Sent from my GT-I9000 using XDA App

Already discussed - its useless on phone. Phone will be even slower.
Sent from my GT-I9000 using XDA App

dupel said:
Already discussed - its useless on phone. Phone will be even slower.
Sent from my GT-I9000 using XDA App
Click to expand...
Click to collapse
Lets save statements like these after it has been actually tested.

KhaaL said:
Lets save statements like these after it has been actually tested.
Click to expand...
Click to collapse
Not everything needs to be tested. If you make a program to draw a circle, it wont make a square, let alone cook eggs. (it's the case for this patch at the technical level, beyond the "wow" words from 1st post)
Note: there's other patches in 2.6.37 for responsiveness which are different from the one spoken about here which are actually likely to improve things. But probably not as drastic.

dupel said:
Already discussed - its useless on phone. Phone will be even slower.
Sent from my GT-I9000 using XDA App
Click to expand...
Click to collapse
Got any links to where I can find out what you know?
I was *hoping* that if it made desktops much more responsive under heavy loadings that it would help with the phone - its not like we have slow cpu's in these things Or is it cpu architecture that allows the improvments and the phones just are not compatible? or something else?
just wanting to know more and to hopefully get a dev who thinks its worth taking a look to see - 200 lines of code - *cof* (ducks behind armour) "how hard could it be?" *runs for cover*
i get this sinking feeling from the subtle - and not so subtle comments from you guys tho - that its just not really suited for how android works on a phone....

cbdrift said:
Got any links to where I can find out what you know?
I was *hoping* that if it made desktops much more responsive under heavy loadings that it would help with the phone - its not like we have slow cpu's in these things Or is it cpu architecture that allows the improvments and the phones just are not compatible? or something else?
just wanting to know more and to hopefully get a dev who thinks its worth taking a look to see - 200 lines of code - *cof* (ducks behind armour) "how hard could it be?" *runs for cover*
i get this sinking feeling from the subtle - and not so subtle comments from you guys tho - that its just not really suited for how android works on a phone....
Click to expand...
Click to collapse
Read last 5 pages in hardcore kernel topic.

knowing one and the other about linux, I have to disagree with those who say: it's gonna make your phone slower..
why? in linux, things constantly run in the background. and what this patch does, is give priority to foreground processes. True, there isn't MUCH in the background, so results may not be super, but the compile with 64 threads is just AN EXAMPLE of what it can do. That's the PERFECT situation to demonstrate. This doesn't mean that it sucks for everything else! It just means that it works
So stop *****ing and just test it before you start yapping that it's bad, doesn't work on phones etc... There is no right and wrong here, there is just: test it and see if it works!
i'd like to have a REAL technical discussion with these people here that are so-called experts... Because their arguments (excusez-le-mot) SUCK.
so please adapt your first post, because what they are saying is just guessing and not based on experiments nor experience, which renders it completely useless
Just my 2 cents

dupel said:
Already discussed - its useless on phone. Phone will be even slower.
Sent from my GT-I9000 using XDA App
Click to expand...
Click to collapse
discussion is worthless, you can't convince me with some "maybe this, possibly that", if you say it's useless: give hard numbers or (sorry, but...) stfu!

UPDATE:
i've been reading up on the lkml and i think there are some very interesting possibilities here...
What this program does, is put the tty-bound processes in a special cgroup. While this is done automatically, there is also a possibility to just do the same in userspace. (check Lennart from redhat's solution).
It basicly creates a different cgroup for foreground processes, he does it in the bash profile. But i think that with this in mind, we can create cgroup handler for our "most important" apps to make them more responsive!
I've been looking into hardcore's kernel and it already has cgroup support built in, so it's actually just a matter of using it properly
how? check lennart's comments further in the lkml thread because you have to look out to clean up cgroups when no more processes use it.
Anyway, when properly tuned, it should be even better than the kernel patch people talked about!

These type of changes would suit more underpowered devices like the Hero or G1 but imho I dont know why the galaxy S needs it, my IO after applying OCLF is 2300+ apps, any lag issues are not due to the current modded kernels available as they are really good..

Idk why people don't understand simple things
cgroups does not magically makes your apps more responsive. It makes groups of processes which are scheduled together at the same level instead of doing it per process.
So, the group of "make" processes during a make -j64 get all globally a lower share of resources (than if they weren't grouped), allowing the group "browser" process to get enough resources to be smooth.
Without, each make process (64 of them) would get an equal resource time, which would also be equal to the browser, which ends up not being very nice for the desktop.
Now on the phone.. do you have a make -j64 running [IN THE BACKGROUND]? nope. do you have an heavy process or group of processes running [IN THE BACKGROUND]? nope.
Your front task is always the one taking most resources. If you put it in a group you might even decrease it's performance and responsiveness.
It's a double edged sword. You see, when they schedule the make -j64 process group, your browser is smooth but the make -j 64 process group is *slower*.
So unless a group of processes on the phone are taking too much cpu (i know of none doing that unless they're on the foreground), it's useless

bilboa1 said:
Idk why people don't understand simple things
cgroups does not magically makes your apps more responsive. It makes groups of processes which are scheduled together at the same level instead of doing it per process.
So, the group of "make" processes during a make -j64 get all globally a lower share of resources (than if they weren't grouped), allowing the group "browser" process to get enough resources to be smooth.
Without, each make process (64 of them) would get an equal resource time, which would also be equal to the browser, which ends up not being very nice for the desktop.
Now on the phone.. do you have a make -j64 running [IN THE BACKGROUND]? nope. do you have an heavy process or group of processes running [IN THE BACKGROUND]? nope.
Your front task is always the one taking most resources. If you put it in a group you might even decrease it's performance and responsiveness.
It's a double edged sword. You see, when they schedule the make -j64 process group, your browser is smooth but the make -j 64 process group is *slower*.
So unless a group of processes on the phone are taking too much cpu (i know of none doing that unless they're on the foreground), it's useless
Click to expand...
Click to collapse
very true... that's why it still might be possible to group "your current task" and "all the rest". That (might) give you an advantage still...
and as said: i'm not saying it IS better, i'm saying it might be worth testing
hence the suggestion i put in post 11: make something that puts the application you start in foreground in a dedicated group and EVERYTHING else in another. When you background that process, move it to the "pool" group
it might just help!! (so... don't shoot the idea too soon )

Related

Slow X, looking for info and/or advice

My X has been running slow and a little funny. I have froyo 2.3.15, with FlyX Rom, Revolution Themes, LauncherPro Plus, and Beautiful Widgets all running. Revolution was the last thing I added about a week ago and ever since then, it seems to be running different. Its slower to react, doesn't change from portrait to landscape very fast, whenever I unlock the screen, if I'm holding it straight up and down, it always opens into landscape mode. This seems like a pretty standard setup to a lot of people on here. Any advice and info on this topic would be appreciated, or just conversation about what others are running similar or different. Thanks a lot!
(also, I ran quadrant benchmark with scores between 1440 and 1495)
brandon2x said:
My X has been running slow and a little funny. I have froyo 2.3.15, with FlyX Rom, Revolution Themes, LauncherPro Plus, and Beautiful Widgets all running. Revolution was the last thing I added about a week ago and ever since then, it seems to be running different. Its slower to react, doesn't change from portrait to landscape very fast, whenever I unlock the screen, if I'm holding it straight up and down, it always opens into landscape mode. This seems like a pretty standard setup to a lot of people on here. Any advice and info on this topic would be appreciated, or just conversation about what others are running similar or different. Thanks a lot!
(also, I ran quadrant benchmark with scores between 1440 and 1495)
Click to expand...
Click to collapse
I cannot recall whether or not FlyX includes the build.prop modifications or not, if not you would definitely want to make those. Other than that the only other thing I would recommend is giving MinFreeManager a shot, it changes the "low memory" requirements for the built in memory manager (task manager) of android. If configured properly it can really make a difference in both battery life and performance (not speed, but responsiveness). It does not do it for you, it lets you set the fields, so learn how to do it first, it varies depending on your use of your phone, I don't run any facebook or other streaming applications so my settings are 6,8,16,60,60,150 but this could vary greatly, and may adversely affect others, so read up on the app in the market.
Again that app will improve responsiveness, in that it will give you less delay when swyping the screen in the UI and such, in that your phone does not have to kill a task to free up memory to complete the next task, it will not improve benchmarks, at the same time, poor memory management will give you poor performance in real world use but may not affect your benchmarks, another reason that benchmarks are poor ways of measuring performance.
Outside of that, what it really comes down to is our Android systems need hardware acceleration... Google really needs to get of there... well... you know... and get with the game here, based off the recent discussion and their advisement to manufacturers to hold of the release of tablets until the next android release, I am hoping they are currently implementing it, but without GPU hardware acceleration in the UI and web browser, we will constantly have the appearance of choppiness and the illusion of poor performance even on our overqualified phones... it is one area where I am sad to say the iPhone has us beat... very sad to say... as a matter of fact, I just washed my mouth out with a bit of soap...
EDIT: a good example of how well that application worked for me over actual "tasks killers" on the market such as task killer and such... before having this app installed and configured, a quick investigation of "settings, applications, running services" and viewing the available memory, it would display "Avail:16MB+98MB in ##" after having this app and having it configured it displays "Avail:72MB+116MB in 26" I am assuming my poor UI responsiveness was due to the first of the two numbers...
Yeah I always hate to say that about iPhones too but they do seem to keep the same speed and responsiveness ALL the time... Oh well, they've been around a little longer so Android will just have to keep working on it. I believe it'll be there soon. I will try that app you recommended. I appreciate the speedy response.
brandon2x said:
Yeah I always hate to say that about iPhones too but they do seem to keep the same speed and responsiveness ALL the time... Oh well, they've been around a little longer so Android will just have to keep working on it. I believe it'll be there soon. I will try that app you recommended. I appreciate the speedy response.
Click to expand...
Click to collapse
no problem, yeah, the iPhone has had GPU hardware acceleration in the UI since it came out, they structured their OS around it, Google chose otherwise, and I can only hope they regret that decision now... but hopefully they will make amends for that...
just make sure you read the post referenced in the app itself. It is written for the HTC Hero which only has 288MB of Ram as opposed to our 512MB Ram, but it still basically applies.
Keep in mind:
It does not automatically set on reboot until you tell it to, do not tell it to until you are sure the settings you have set do not mess with anything.
You probably will not notice a difference for about an hour... at least that's how long it took for me to truly notice a difference... I'm not really sure why, it apparently took that long for the priorities to take affect, and get the right processes killed, etc., etc. After that, especially later that day I was truly noticing a difference, especially in typing... I have always had a delay when typing on this phone, and that seems to be gone now...
yeah i was guessing that. i read an article at androidcentral.com about it and just set it to aggressive for now. applied it, but the specs under "running services" haven't changed so i'll give it an hour or so. i'll let you know how it turns out. thanks again!
brandon2x said:
yeah i was guessing that. i read an article at androidcentral.com about it and just set it to aggressive for now. applied it, but the specs under "running services" haven't changed so i'll give it an hour or so. i'll let you know how it turns out. thanks again!
Click to expand...
Click to collapse
Sounds good, your welcome and good luck!
If those settings work out for you without any problems, you'll probably want to up them a bit, it might say aggressive, but they are only so aggressive... If it makes a big difference for you then stick with them, if you still have slow down, and you are running what you described before, you can probably get away running settings similar to what I posted, just don't have them set on boot just in case, if they don't work out you can always set them lower or back to a preset. It is definitely something you can expiriment with, if worst comes to worst, you can always reboot, but as long as you don't touch the first 4 values, you won't mess anything up, the worst that you will do with the last 2 is temporarly screw up facebook sync. or something similar, and really you can get away with changing the 4th value to, it just has a chance of affecting more things, but I doubt you'll end up affecting anything with values around 50 anyway. Like I said, experimenting never hurts, slow phones do... Just keep an eye on it ;-) good luck again.
To add a little correction.if you are running fly x then you are not running 2.3.15 you are running the earlier related release it Is based on. Even if you did have2.3.15 before installing it fly x over writes the system to the files it uses. All roms do. Do you actually have like 2.3.9 I think
Sent from my DROIDX using XDA App
It does say 2.3.9. I inquired about this before because I used teamblackhat to get .15 and the system never seemed to change to .15 every time I tried to download it... I guess that's why, because of flyx...
Sent from my DROIDX using XDA App
After reading Captian Taco's post I was eager to try it out, and its actually making a big difference =D thanks!
Yes it is... its been running much smoother and more responsive all day. Thanks again captaintaco... (boy thats kinda funny to type...)
Sent from my DROIDX using XDA App
Thanks CaptainTaco! Installed MFM to clear up my "lag" issues that are usually experienced in the evenings after a reset first thing in the a.m. each day. Before MFM it wasn't a huge deal to do a reset to clear up the issue, but I much prefer it to just work right all the time.
pduboise said:
Thanks CaptainTaco! Installed MFM to clear up my "lag" issues that are usually experienced in the evenings after a reset first thing in the a.m. each day. Before MFM it wasn't a huge deal to do a reset to clear up the issue, but I much prefer it to just work right all the time.
Click to expand...
Click to collapse
Hey don't thank me, thank the creator of MFM, I'm pretty sure he was one of the first to discover the power of Androids integrated minimum memory management, if not the first. Just glad to share my discovery of his discovery haha. But yea, to be honest I don't even use a custom Rom anymore, it runs so quick just having that (thought it works even better in conjunction with your standard simplistic task killer such as "advanced task killer" just to kill apps in the foreground after you are done with them, since many apps don't include a way of closing themselves out...
I still try the custom Roms out and play around with them for the hell of it, but as for right now, I rely heavily on corporate integration, and most of the good blurless Roms remove features required for true and proper corporate sync, such as calender sync and the like... and I just don't like touchdown pro... So this helps me out greatly... remove some bloat, throw launcher pro on there, and get this fix fired up, phone runs like a dream... now if only they could get exchange active sync running like it was on Sense... best implementation I have seen of Exchange active sync so far... I do miss that...
Well after all the advice I ended up installing the zapx rom last night. Wow! It is sooo fast... everything just responds and reacts so much faster than before. I suggest installing zapx to anyone. Best rom so far I think...
Sent from my DROIDX using XDA App

Android accelerator - A Magic runs same speed than a Nexus

Hi all,
Very impressed after watching this video on the Cyanogen Mod :
Demo video : http://forum.cyanogenmod.com/topic/...aster-flexycore-thanks-cyanogenmod-community/
I m pleased to share it with you and would like to know what you're thinking about this "droidBooster" which make an old HTC running at the same speed than a Nexus One! :
Whats the point of this?
What does a video of a video player proove? Wouldn't some real time benchmarks like linpack or quadrant be more proof.
Still why didnt they have 2 Nexus One's and show how much faster the one with droidbooster got.
All these booster softwares sound abit like all the BS booster softwares for windows.
sceptical...
Hmm I suspect that they are overclocking because they didnt mention anything about clock speed but lets hope that its legit
Edit: they have an apk in the market
Sent from my Nexus One using Tapatalk
Imperial.mack said:
Hmm I suspect that they are overclocking because they didnt mention anything about clock speed but lets hope that its legit
Sent from my Nexus One using Tapatalk
Click to expand...
Click to collapse
I hardly think they are overclocking becose that would make the software only runnable on rooted devices. Which would remove a huge part of their possible market share.
And overclocking with that much improvement in performance? Youd have to double the clock rates. Which on nearly all devices is damn close to impossible. Except for Desire-Z for example.
Unless they somehow are without Root overclocking it or changing the kernel to their own super optimized i dont really see how this is done.
nd the nexus one can fly beyond their limits?
They posted this video showing how it works basically:
http://www.youtube.com/watch?v=tEAz9fRoDmA
Their software modifies the Dalvik code, which means that you do not only need to be root, but you also can't install this software without modifying your ROM.
From the web page http://www.flexycore.com/droidbooster-overview.html
"DroidBooster technology enables to compile any Android Java code in optimized native binary when generating the ROM, taking full power of the underlying CPU for high performance and low power execution."
This is not overclocking, but maybe be a paid app (and very expensive app)
Sorry 4 my poor english
It's actually more like Jit.
See this video for further explications : http://www.youtube.com/watch?v=tEAz9fRoDmA
Lol ok took me so much time to answer that already 4 ppl posted !!
After looking at the company website who developed DroidBooster, I discover an other Video with a principle presentation of droidbooster.
"DroidBooster relies on compiling and executing any embedded Java Code of an Android system as binary." according to the video available here:
ww.youtube.com/watch?v=tEAz9fRoDmA[/url]
this thing is kinda bs imo. And the guy's voice is just gay
LoL
I hope to come out soon
If this thing really does what the company claims, then Google will probably buy the code from them. Also limiting this software to rooted phones means it wouldn't make a ton of cash, and then expecting them to cook and sign their own ROMs is a weird business model. In other words, it's meant for developers only, so we kinda have to wait for official incorporation.
exciting! hope they support the nexus ..
DDM123 said:
If this thing really does what the company claims, then Google will probably buy the code from them.
Click to expand...
Click to collapse
No, I doubt this code is worth anything to google. All they say they are doing it converting the dalvic code into native code. If google wanted to do that they could very easily, the JIT they included with Froyo already does do it to some extent.
I won't believe this for a second. I have both the N1 and Magic, and I can safely say the N1 is MUCH faster. It should be a no-brainer, just look at the specs. The Magic was what -- the second Android ever!? They were bound to improve, and the N1 set the bar high a year ago. Now look at the plethora of fast devices we have, and the N1 can be thanked for that. I once read that one of the reasons Google launched the Nexus was to jump-start the "super" smart phone market, because manufacturers weren't pushing the bar far enough in their devices. N1 set a standard for the rest of them. The way I see it, the Magic was nothing more than an early experiment.
And I never had an issue playing videos on my Magic anyway. What proof is that? The N1 is definitely more responsive, boots 10x faster, never runs out of memory. The Magic pretty much requires an app killer; never needed one on the Nexus. I can go on and on, but I think I made my point.
Bloodflame said:
I won't believe this for a second. I have both the N1 and Magic, and I can safely say the N1 is MUCH faster. It should be a no-brainer, just look at the specs. The Magic was what -- the second Android ever!? They were bound to improve, and the N1 set the bar high a year ago. Now look at the plethora of fast devices we have, and the N1 can be thanked for that. I once read that one of the reasons Google launched the Nexus was to jump-start the "super" smart phone market, because manufacturers weren't pushing the bar far enough in their devices. N1 set a standard for the rest of them. The way I see it, the Magic was nothing more than an early experiment.
And I never had an issue playing videos on my Magic anyway. What proof is that? The N1 is definitely more responsive, boots 10x faster, never runs out of memory. The Magic pretty much requires an app killer; never needed one on the Nexus. I can go on and on, but I think I made my point.
Click to expand...
Click to collapse
Not really. The point is that this guy is claiming to make java code run in native binary, thus ensuring that the CPU isn't doing unnecessary work to interpret and run java code. If possible (who's to say) then it would make a Magic run much faster than it does. It might even be feasible to suggest that it would run as fast as a stock Nexus.
Think about it this way, why is it that the original iPhone UI is so smooth? The code is optimized and run as a native binary, not some VM that has to be compiled and run by the CPU every time it wants it. Native code would make the Magic much faster.
The whole point is moot though, because this isn't something that you will see bundled into an .apk anytime soon. It might be novel code that Google picks up on and uses in later OS revisions though. Who knows.
sassafras
As i understand it will cost a high memory consumption, where 512mb of ram will be not enought for it (Actually its already not enough on miui rom with Dalvik VM, on nexus1 i have only 130mb free). And high power drain.
Welcome back to Windows Mobile
Btw i dont believe it, they just want to make some money with air bubbles
Tim4 said:
As i understand it will cost a high memory consumption, where 512mb of ram will be not enought for it (Actually its already not enough on miui rom with Dalvik VM, on nexus1 i have only 130mb free). And high power drain.
Welcome back to Windows Mobile
Btw i dont believe it, they just want to make some money with air bubbles
Click to expand...
Click to collapse
"Only" 130MB free? It's 130MB that isn't ever used by the system, making it wasted 130MB, and you're referring to it as "only"?
This point was discussed zillions of times in Autokiller Minfree and "Don't need task killers" threads. Android has efficient memory management, Nexus having it VERY efficient since Froyo, much more efficient than really needed. It never uses its 400MB of user memory or even close to it.
Funny, how marketing affects people. They want more of the things they don't need.
Jack_R1 said:
"Only" 130MB free? It's 130MB that isn't ever used by the system, making it wasted 130MB, and you're referring to it as "only"?
This point was discussed zillions of times in Autokiller Minfree and "Don't need task killers" threads. Android has efficient memory management, Nexus having it VERY efficient since Froyo, much more efficient than really needed. It never uses its 400MB of user memory or even close to it.
Funny, how marketing affects people. They want more of the things they don't need.
Click to expand...
Click to collapse
Yeah, i call it "the only free memory."
Take a look:
You have 130mb left.
1)browser eats 65mb of ram. 65mb left
2)+some other apps that running at background/service.
So what i have in result?
My apps often be killed by android because out of memory.
The most anoying thing is when im surfing, writing some stuff on forums i get my browser killed with data lost. Its rare but still hapens.
Another real example: Dungeon Defenders. When i play it, i got almost all my apps be kicked from memory.
P.s. I know about wipe. Just moved to latest 1.1.14miui, have wiped everything 3 times.
P.s.2 ofcource it depends on how many apps you have and which rom you use. No problems with ram on stock android but i just dont like it, so...

[Q] TRUE Multi Tasking

Will android ever get REAL TRUE Multi Tasking? not the app switching that it has now but real multi tasking like webos and bb playbook os, would developers be able to add this somehow to tablets on their own? or could we port other os like webos and bb os to our tablets when wanting or needing true multi tasking
Rodriguez92 said:
Will android ever get REAL TRUE Multi Tasking? not the app switching that it has now but real multi tasking like webos and bb playbook os, would developers be able to add this somehow to tablets on their own? or could we port other os like webos and bb os to our tablets when wanting or needing true multi tasking
Click to expand...
Click to collapse
android already handles asynchronous threads. that' is "REAL TRUE" multitasking. and android already has background processes running along with apps running in the background.
on a mobile device, there isn't enough screen real estate to show two apps running, so that's never been a priority for android, it's not a case that it can't do it.
as for tablets, i'm sure if not already, it's coming.
I meant multitasking like have a youtube video running n writing an email at the same time. In android if you switch out of youtube the video pauses even though it stays running un the background. I would like things to keep running as if I was still in that application. On tablets im not talking about mobile devices.
Sent from my SGH-T959 using XDA Premium App
MarkusPO said:
as for tablets, i'm sure if not already, it's coming.
Click to expand...
Click to collapse
if you really want that,buy a laptop. tablets are in an early stage of development. as an early adopter you need to put up with the tech while it's being developed.
I have a laptop n a desktop that's not the issue but if my tablet is just as strong as some laptops why not be able to do these things. Im just asking can we port or will we be able to do it at some point if you didn't realize the question.
Sent from my SGH-T959 using XDA Premium App
Rodriguez92 said:
I meant multitasking like have a youtube video running n writing an email at the same time. In android if you switch out of youtube the video pauses even though it stays running un the background.
Click to expand...
Click to collapse
It's a feature. YouTube intentionally pauses playback, but it does not have to - it could play in the background. So Android has "REAL TRUE" multitasking, but YouTube doesn't use it that way you want.
so what about videos on the device can those keep playing? one thing on the playbook that i really like and was hoping we could get on android was being able to do one thing when your device is plugged into your tv on the tv n doing something else on the tab for example playing a game on the tab n watcxhing a movie on the tv thats playing on the tab
I'm not sure about that, but I think there is no API for displaying something on a TV, so if you have some kind of TV-out in your device, it'll probably just clone the main screen. But speaking of multitasking, it's possible to play video and some game simultaneously - it's just impossible to display and control both of them
MarkusPO said:
android already handles asynchronous threads. that' is "REAL TRUE" multitasking. and android already has background processes running along with apps running in the background.
on a mobile device, there isn't enough screen real estate to show two apps running, so that's never been a priority for android, it's not a case that it can't do it.
as for tablets, i'm sure if not already, it's coming.
Click to expand...
Click to collapse
Android is naturally single threaded. You can handle asynchronous threads, but your context is manually set ( yeah your global vars will get clobbered, unless you handle context switches). You dealing with stacks? You even hear of recursion?
I can prove it to you in an app.
Take mail, build two accounts with different pwds and hosts.
Start a long download on one.
Try a short download with the other.
The asynchronous top level will allow the context switch, the single threaded android bottom end will loose context while spinning on a lock.
Java was outdated 15 years ago ( great graphics on a sparc station), but needs guts now.
The interpreter loader would have to be able to build data structures dynamically, so as to allow examples like the above to run correctly.
SO APKS WOULD CHANGE SIZES as they ran.
OR a limit to the number of mail accounts would have to be preset.
OR a monolith APK bundle (htc sense 3 ) would have to be created.
IMHO
Rodriguez92 said:
I meant multitasking like have a youtube video running n writing an email at the same time. In android if you switch out of youtube the video pauses even though it stays running un the background. I would like things to keep running as if I was still in that application. On tablets im not talking about mobile devices.
Sent from my SGH-T959 using XDA Premium App
Click to expand...
Click to collapse
Youtube does that on purpose to prevent you from just using it as a music streaming service, you can listen to Pandora or Last.FM while writing an Email or pretty much anything else.
willy900wonka said:
Android is naturally single threaded.
Click to expand...
Click to collapse
Err... Android is single threaded? ;-) I think you meant "apps for Android" instead of "Android" and "single process" instead of "single threaded". Of course apps are multi-threaded. Same for Android OS - it's not only multi-threaded, but even multi-process.
But you're right: most of Android apps use only one process, so one context, etc. It's possible to run your app in several processes, but you can't spawn them whenever you want - you have to define each process in AndroidManifest.xml.
You should take into account that multiple processes aren't good, because device uses some RAM for each process you will create. You could run 2, 5 or 8 processes, but when you try to create 10th one, your device will run out of memory and some of your tasks will be killed. But if you redesign your app, so it will manage all of these task in one process, then this will take minimal amount of RAM and will give you exactly the same possibilities.
Of course Android isn't Apple, I think that should be a choice of an app developer, not Google. But they would have to add some API for this and they know it would be totally impractical, so I think they just don't want to waste their time on that
willy900wonka said:
You dealing with stacks? You even hear of recursion?
Click to expand...
Click to collapse
I think you should learn OOP and multi-threaded programming ;-) Recursion? What's the problem? If you run recursion on instance A of some class X and second recursion on instance B of X, then they won't even know of each other.
Single-process doesn't mean there is always one instance of each class. If you use singletons and/or static methods where you shouldn't, then it's your problem.
willy900wonka said:
Java was outdated 15 years ago ( great graphics on a sparc station), but needs guts now.
Click to expand...
Click to collapse
Err.. what? ;-) Java was created 15 years ago, it's up-to-date language right now and it's still developed quite rapidly. Also if you think about these problems with single-process, then this isn't caused by Java, but Android OS.
willy900wonka said:
The interpreter loader would have to be able to build data structures dynamically, so as to allow examples like the above to run correctly.
SO APKS WOULD CHANGE SIZES as they ran.
Click to expand...
Click to collapse
I have no idea, what are you talking about
willy900wonka said:
OR a limit to the number of mail accounts would have to be preset.
OR a monolith APK bundle (htc sense 3 ) would have to be created.
Click to expand...
Click to collapse
OR learn how to properly write multi-threaded applications ;-)
i assume op has never listened to music while browsing the internet. if that isn't "true multitasking" then i don't know what is
anyway, i think this thread was a mistake on op's behalf
willy900wonka said:
The asynchronous top level will allow the context switch, the single threaded android bottom end will loose context while spinning on a lock.
Click to expand...
Click to collapse
Locks only apply to concurrency, no?
An interesting discussion about how to manage Binders and IPC and Threads at the native level I found:
http://groups.google.com/group/andr...hread/thread/532f2ec1d17eadf/5cb6a1491fb23274
I'm not very well versed at the low level stuff, but having Threads and Binders and IPC would indicate to me a multi-threaded environment.
This is a quote from Diane Hackborn who's one of Android's framework engineers:
(from 2009)
...multiple processes is a key aspect of Android and making it relatively easy to deal with that (mostly so far at the system level) is important.
Click to expand...
Click to collapse
So yeah, process scheduling has to occur at some point when you only have one processor, and it seems you can grab a nasty deadlock via native code, but none of that implies single threadedness. This is obviously not to mention Binders and IPC/AIDL and Threads at the Java level.
Anyways this thread sparked my interest to read about this stuff more, so thanks all you guys for that. Now I'll never fall asleep
Edit: also found this interesting overview of Bionic (Android's version of libc)
http://www.netmite.com/android/mydroid/1.5/bionic/libc/docs/OVERVIEW.TXT

V6 Supercharger

So do you guys use it and what does it exactly do? And also what does 3g turbocharger and kick ass kernel tweak do?
Basically everytime the memory drops below the thresholds set by v6, the system will start killing of apps running in the background which frees up memory that you most probably aren't using, Im currently on the aggressive settings so everytime my memory drops below 150mb the system starts killing apps. Its basically just tweaking the internal task killer to be slightly more aggressive. It also locks the launcher so the system cannot kill it if the memory drops too low.
The 3g tweaks, I think adjust or add some settings to the build.prop which supposedly make it faster although I haven't noticed much difference with that and the kernel tweaks I'm not too sure where the changes are made but again I don't see a great change from it. Definitely recommend v6 supercharger though.
Sent from my HTC Wildfire using xda premium
Scratch0805 said:
Basically everytime the memory drops below the thresholds set by v6, the system will start killing of apps running in the background which frees up memory that you most probably aren't using, Im currently on the aggressive settings so everytime my memory drops below 150mb the system starts killing apps.
Click to expand...
Click to collapse
Great. Let's take 150MiB of RAM and then don't do anything useful with it. Processes aren't supposed to be killed unless you actually run out of memory.
Scratch0805 said:
It also locks the launcher so the system cannot kill it if the memory drops too low.
Click to expand...
Click to collapse
That seems innocent, but it won't help you if the launcher has a memory leak. If the launcher kept getting killed, it was telling you that your low memory thresholds are too high. Under normal circumstances, the launcher won't get killed. But if it grows too much, it'll get killed and the OS won't crash.
When you force close an application through the application manager, it shows you a warning. There's a reason for that (exactly what it says). And since Android 2.2, the framework can take care of itself just fine. No need for any 3rd party task killers.
Lol..... Thought you'd have something to say on it, actually mate the way my phone is usually setup there is nothing running in the background to kill anyway, thanks to autostarts I only have apps running that I need and make sure that I close things properly after use, so it really doesn't matter which settings I use whether they be low such as 30mb before it starts killing the first lot of empty apps or high such as 150mb as my setup rarely drops below because there is only the bare minimum running in the first place.
Sent from my HTC Wildfire using xda premium
Allright, it's not that RAM would slowly wear and tear by using it but at least you're not buying that it's better for performance. And I just wonder how these apps are made, as a thought experiment to figure out the mindset of whoever wrote this task killer.
...So let's make an app which looks real cool and doesn't do anything useful in particular! Wait, no one would download that! Hmm... Oh, I know! Let's call it "V6 Supercharger"! Yeah, that sounds awesome! Now people will download it for sure! It's the coolest thing since sliced bread!
It's the same with those programs like "Registry Booster". How did that happen? Someone must've woke up one day, turned on his PC, started poking in the registry, saw lots of keys which aren't really strictly necessary but are there anyway and thought like "Hmm, what if I made a program which removes all these unneeded keys? MS-Windows would be ZOMG faster!!111eleventyone". Then made it look real slick with a custom skin and a speedometer showing progress and say at the end that the registry has been "boosted". And since this guy is such a nice fellow, he threw in some extra free toolbars into the mix as well. Users always appreciate having more toolbars to click on and agreements to ignore.
Ok, I'll stop ranting now. Enjoy your week
Try explaining that to the dev who created it here. Honestly, it would be better, because, I am pretty sure most members here are not as technically inclined as you.:
http://forum.xda-developers.com/showthread.php?t=991276
You're just setting him up so I can tear him apart... aren't you?
The poor bastard doesn't even know what it is... he thinks it's a task killer app... heh
No, I would like him to discuss all the technical aspects with you. Because, clearly, he's wasting his effort as a developer here educating non-technical people like me, and the majority here on the Wildfire Forums.
And before you accuse me of trying to set people up, I can assure you I have nothing against you / your script or anything. Rather, I have used your script, and came away impressed with it.
I know you you weren't doing anything like that... I'm always putting down these clowns that think that suffocating the phone is good... idiots lol
Like I say, what the hell good is phone if you can't make a call because of some crap hogging the ram?
Besides, I doubt very much he has any technical skills at all... like I said before, he doesn't even know what it is so he's not very techinical
dud3me said:
what does it exactly do?
Click to expand...
Click to collapse
It makes you feel good.
And I definitely noticed a 0.00001ms speed difference when opening apps.
Another liar
zeppelinrox said:
Another liar
Click to expand...
Click to collapse
Yeah lol. Most people in this forum are wannabe developers who know **** about developing but they like to act like they do. Apart from few people who actually know stuff and the others like me who acknowledge the fact that we don't know anything
Fact is, those who know they don't know learn more than those that think they know it all
Less than a year ago, I knew 0 about android.
And when I started the supercharger script, I knew nothing about linux scripting.
Just started off with a few commands and everytime I wanted to try something new or add something... I googled it up.
And I'm still figuring it out.
For example, I set my 256mb device to have 25mb free with the number I use in slot 3.
So whatever memory tool I use will show I have 25 or 30mb free... great - that's what I want
But when I was doing up the recent update and enhanced the Fast Engine Flush, I wanted to show before and after using the "free" command.
To my surprise, system tuner shows that I have 30mb free while the free command shows I have only 5mb free!
So what's that mean? Why that difference of 25mb?
It means that all that "free ram" is actually being used for cache.
And it's giving me speed
So to those that think it's great to have ram clogged with apps when the system is starving for space to use for cache...
BOOYA!
Really have trouble using your scripts and I think after enabling 3gturbotweak thing my 2g data isn't working haven't tried 3g.
I can't recall it affecting 2g... so I assume 2g used to work (I don't get 2g - it's unavailable)
But if you unturbocharge, the 2g/3g goes back to normal, no?
zeppelinrox said:
I can't recall it affecting 2g... so I assume 2g used to work (I don't get 2g - it's unavailable)
But if you unturbocharge, the 2g/3g goes back to normal, no?
Click to expand...
Click to collapse
Well I had to format system data and cache and wiped everything and now it's working again so I'm not completely sure if it was the turbocharge thing.
The idea that you can magically "supercharge" your OS by freeing up memory is fundamentally flawed.
what the hell good is phone if you can't make a call because of some crap hogging the ram
Click to expand...
Click to collapse
If this is really a problem on your phone, you're doing it wrong. I haven't done anything to free up ram and the amount of ram available on my wildfire is currently 108,48MiB. I start 10 random apps, Angry Birds, and Angry Birds Rio. 40,68MiB still free. I start Angry Birds Seasons and end up with 49,66MiB free and 9 apps died, including the first angry birds. Running out of ram is in general not a failure mode of Android and at no point was I unable to place a call. I close the 2 remaining open instances of Angry Birds the normal back-button way, 147,68MiB free.
I'm always putting down these clowns that think that suffocating the phone is good... idiots lol
Click to expand...
Click to collapse
I just wanted to quote that.
And when I started the supercharger script, I knew nothing about linux scripting.
Just started off with a few commands and everytime I wanted to try something new or add something... I googled it up.
Click to expand...
Click to collapse
That's exactly the impression I had. Now take it from someone who has run Linux both embedded and on his desktop for the past 12 years. Your app doesn't improve anything, and I'd be glad to be proven wrong because you would've actually made a discovery we can use to improve Android and Linux with. From your post I understand it you change vm kernel parameters such that the oom killer is invoked sooner. This is actually detrimental to the stability of the OS, the oom killer is only meant to be invoked as a _last_resort_. The Android framework has its own means to free up memory, including calling onLowMemory in any application and doing a gc run. This does not cause instability and is completely transparent to the user. I've only ever had to manually kill applications in a broken state and others for debugging purposes, which is why the Force Close button exists.
It means that all that "free ram" is actually being used for cache.
And it's giving me speed
Click to expand...
Click to collapse
If the output looks anything like this:
Code:
total used free shared buffers cached
Mem: 3456 3325 131 0 10 93
-/+ buffers/cache: 3221 235
Then you've just never bothered to look. You can clearly see in the second line it makes a calculation for you which is exactly what it says in the leftmost column. And of course completely disregard the fact that cached pages are invalidated on a write (marked dirty) and reads from an mtd are really fast already anyway.
So to those that think it's great to have ram clogged with apps when the system is starving for space to use for cache
Click to expand...
Click to collapse
This is not how it works! For starters, ram cannot be "clogged". A drain pipe can be clogged but ram is made of digital circuitry, not plumbing. And second, there is no resource starvation in the page cache. It's just an old optimisation to keep data pages in memory for longer to serve repeated reads and give them back whenever they're needed for something else. More apps in ram can actually mean less reads are necessary because the data is already there (especially if you tend to switch between recent apps). Since Android 3.0, application developers are encouraged to use Loaders which cause filesystem I/O to be performed on a background thread. And applications which actually use the available ram always trump applications designed to use as little ram possible in performance. Between a collection of loaded objects and a cached filesystem, the collection always wins. You have 256 to 512 MiB of RAM in a typical Android device. The average application is 18 to 30 MiB. It can manage. Especially when you consider the fact that the UI only shows 1 task at a time and pressing the back button usually destroys the activity you were in. The gc takes care of its remains.
Now here's something which will actually improve write speeds on /data: Open up settings, applications, manage applications. Sort by size. Remove the biggest apps you don't need and move the rest to SD if you can (you can use "pm setInstallLocation 2" as root to move non-froyo-aware apps to SD). I've been using the market a lot lately so I just removed aDosBox, Albert Heijn, PocketCloud, Pulse and moved Dolphin Browser to SD which meant 47.25MiB free on /data. On a 175MiB partition, 30% of it is about 52MiB so I'd try to keep the available space around 50MiB. If your phone is low on storage, doing this will perceivably improve performance.
dud3me said:
Well I had to format system data and cache and wiped everything and now it's working again so I'm not completely sure if it was the turbocharge thing.
Click to expand...
Click to collapse
Same thing happened to me, but every time i turned 3g on the phone rebooted and i got stuck in a bootloop, i had to use the ruu update to restore phone.
I would stay away from the network tweaks. It doesnt improve speed anyway.
Sent from my HTC Wildfire using xda premium
henkdv said:
The idea that you can magically "supercharge" your OS by freeing up memory is fundamentally flawed.If this is really a problem on your phone, you're doing it wrong. I haven't done anything to free up ram and the amount of ram available on my wildfire is currently 108,48MiB. I start 10 random apps, Angry Birds, and Angry Birds Rio. 40,68MiB still free. I start Angry Birds Seasons and end up with 49,66MiB free and 9 apps died, including the first angry birds. Running out of ram is in general not a failure mode of Android and at no point was I unable to place a call. I close the 2 remaining open instances of Angry Birds the normal back-button way, 147,68MiB free.
Click to expand...
Click to collapse
All that you said is very informative.
What are your minfrees?
Set them to something like 6, 12, 16, 18, 26, 30.
Run a bunch of apps...
See how great it runs then
Fact of the matter is, user's with 1GB ram devices notice a real improvement.
Not placebo.
Pressing the home or back button has an instant effect without hesitation - which indeed happens on stock roms.
Yes in theory I'm sure it all makes sense and I apologize for using layman's terms such as "clogging".
An android phone is not a Linux PC so I believe it's not a great idea to configure it like it is a Linux PC.
They have difference purposes.
Anyway, in theory, a bumble bee can't fly - but it does.

Super Touch , smooth scrolling. Need help dissecting it.

There is this app called Super Touch that phone arena covered. Supposed to smoothen the touch experience on android by a significant margin. The developer offers no explanation as to how the app works. I've yet to test it because it is building something right now and it takes a long while to finish. From what i can make out , i think it builds some sort of scrolling cache and offloads them to GPU ? I don't know the internal android structure that well and analyzing the source if there is one , is beyond me. If there is a developer that can explain the intricate workings of this app to people , so people could stop comparing this to "snake oil" if it's legit , if it's not we can ask google to remove it from google play , that'd be great. Thanks.
The link to the article ;
http://www.phonearena.com/news/Spot...d-up-your-sluggish-Android-smartphone_id75851
I don't know if it is against forum rules to post links to articles , if it is please warn me and i will remove the link.
boltthrower56 said:
I don't know the internal android structure that well and analyzing the source if there is one , is beyond me. If there is a developer that can explain the intricate workings of this app to people , so people could stop comparing this to "snake oil" if it's legit , if it's not we can ask google to remove it from google play , that'd be great. Thanks.
Click to expand...
Click to collapse
Why is this such a great deal?
Pros
* It seems to work
* It passed google's requirements and malware checks
* Does not need root
Cons
* Closed source
Just because we (you) can't comprehend how it works, is not a reason to question its viability.
Keeping it closed source and not revealing its workings is just a way to prevent competition and/or code copying.
There are lots of fake apps that pretend to be doing something you should be more worried about.
I wouldn't really worry about this one, but if you don't trust it, don't use it.
To answer your question; I would say its either one of these
* Animation caching
* Reducing element-sizes, and thus stretching it to save system resources (since the app needs to know you screen resolution)
* System optimizations for animations (Altho these things usually require root)
On a side note, since you are posting this on the Nexus 4 forums, I assume you own/use one. The article you linked clearly says older devices benefit more from this app, since newer/better devices already handle things pretty smoothly. This means that the result of this app on a Nexus 4 may be unnoticeable. Could it be that you question this app because you don't see any result?
MerynGoesAndroid said:
Why is this such a great deal?
Pros
* It seems to work
* It passed google's requirements and malware checks
* Does not need root
Cons
* Closed source
Just because we (you) can't comprehend how it works, is not a reason to question its viability.
Keeping it closed source and not revealing its workings is just a way to prevent competition and/or code copying.
There are lots of fake apps that pretend to be doing something you should be more worried about.
I wouldn't really worry about this one, but if you don't trust it, don't use it.
To answer your question; I would say its either one of these
* Animation caching
* Reducing element-sizes, and thus stretching it to save system resources (since the app needs to know you screen resolution)
* System optimizations for animations (Altho these things usually require root)
On a side note, since you are posting this on the Nexus 4 forums, I assume you own/use one. The article you linked clearly says older devices benefit more from this app, since newer/better devices already handle things pretty smoothly. This means that the result of this app on a Nexus 4 may be unnoticeable. Could it be that you question this app because you don't see any result?
Click to expand...
Click to collapse
No , it could not be because i had not tested the app when i wrote that. (Had you bothered to read , you'd know.) We question everything on this forum , that's how we learn. I did not assume that it was "fake" by the way , if that's why you're hostile (and arrogant). People on other forums compared this to "snake oil". I wanted to share the app with friends so it could grow. That's why i wanted to make out how it works. I can't share this app before knowing that it's not "snake oil".
When i said i'm not "that" affiliated with Android ecosystem , i didn't mean i'm illiterate btw.
Anyway , i could already make those out from the description of the app (Yes , i too read it ). I wanted more of a technical answer but thank you , nevertheless...
On a side note , In a help thread please just answer the question if you can , skip the lectures people didn't ask for. I asked "available devs" to explain the intricate workings of an app so as to clear the air , not only did you not provide that but you tried to give me a lesson on morality. Please refrain from doing that. And please do not write a lengthy and angry reply to this. I'm just not interested in arguing with you.
boltthrower56 said:
I don't know the internal android structure that well and analyzing the source if there is one , is beyond me.
Click to expand...
Click to collapse
Made me think you were new to Android development and coding in general. Normally people like this with these questions do not want/need a specific and technical answer which is why I told you to not worry about it.
I don't know if it is against forum rules to post links to articles , if it is please warn me and i will remove the link.
Click to expand...
Click to collapse
Again, made me think you were new here.
if it's not we can ask google to remove it from google play , that'd be great.
Click to expand...
Click to collapse
This sounded to me as if you just wanted it to be removed.
My post was not intended to sound the way you describe it, and reading it again I wonder how you came to the conclusion I was 'teaching you a lesson'. Just because I did not overflood my post with happy smileys and kind words does not mean I'm hostile and/or trying to be arrogant.
To me, your post sounds the exact same was as how you described mine.
That aside, here are my technical thoughs.
The app stores quite a lot of data on your phone, close to 7MByte on my phone, to an app-size of 2,86MByte, so I assume it makes use of some kind of caching.
It probably uses some other techniques for different element optimizations, meaning not all improvements are via caching.
My guess is it takes the animations it knows, and "replays" them, capturing the animation and storing it in its data for quick access. When you start the app and set it up, it needs time and says "building fast event for x action", which is why I think it works this way.
From the app:
When using the same smooth level, the better the GPU performance is, the smoother the operation wil be. If the GPU performance is not up to the demand, it may cause frame loss when sliding screen. Higher level may take longer time to start, a better CPU may take less time.
Click to expand...
Click to collapse
The animation is probably "scaled" down in size, which makes it less computing-heavy. This also explains why the higher the setting, the longer it takes. (more compression = more computing power needed. Since a better CPU can do more instructions per second, it will be faster at rendering its own "database" of the animations, which is logical.
Not sure what the author meant with "better the GPU performance is, the smoother the operation will be". Operation could either refer to the process Super Touch does, or the process of animating the animation when using the phone. Personally I think this refers to using the GPU for rendering animations normally (without Super Touch), which can cause frame drops as he explains. GPU's with lower performance will have a harder time rendering an animation than a GPU with high preformance. Pre-rendering takes this load off of the GPU, making it more "smooth" in real performance.
With this method its can just 'grab' an animation from its memory and 'play' it instead of calculating it on-the-fly.
Looking at the permissions the apps needs, the app uses "draw over other apps". This is probably used to "show" the animations it stored instead of the animations of the app that is being used. How it is actually able to replace this animation is something Im not sure of.
The app has permission to run at startup, this is probably needed to "load" the core service that does this replacement.
I do not exactly know why it needs permission to read phone status & identity and change audio settings, but my guess would be that it is related to the power saving mode.
The developer offers no explanation as to how the app works.
Click to expand...
Click to collapse
Unless he does, we can probably only assume how his app works. Decompiling the app and looking at the source might give you an answer, but this is not something I can help you with, mainly because my last decompiling experience is 3 or 4 years back.
Using it for 2 days. And I have to admit that it works, really well, without harming battery, which is a amazing win-win solution.
I asked on the Google play store and get the answer from the developer: the app offload the working process from the CPU to the GPU, hence everything gets much smoother and the performance level depends on your device's GPU.
After optimization, sliding is very smooth.

Categories

Resources