Related
I just recently learned about modify the build.prop...and I came across camera build.prop tweaks and I was wondering if they were necessary for the epic touch 4g.
the tweaks i found were:
ro.media.capture.maxres=8m
ro.media.capture.fast.fps=4
ro.media.capture.slow.fps=120
ro.media.capture.flash=led
ro.media.capture.flashMinV=3300000
ro.media.capture.torchIntensity=40
ro.media.capture.flashIntensity=70
ro.media.panorama.defres=3264x1840
ro.media.panorama.frameres=1280x720
ro.camcorder.videoModes=true
My phone is rooted with Blazer Rom and has the lastest El26 modem...I use the thunderbolt script package...and crawj's modified high bit rate camera...
thanks in advance
Couldn't tell you honestly. I don't use build.prop camera edits - mine are done in the media_profiles.xml located in /system/etc
Most edits in the build.prop so far have been disproved to do anything. I think at one time long ago Android may have used the build.prop for certain settings but now I think it's more or less just an info file for some programs to read. That way they know which settings to use, applications available, or information to display.
Not saying Crawj doesn't know what he's doing - he's a great dev. However we all know too well that old habits or ways of thinking die hard. Happens all the time with technology. Just my personal opinion.
KCRic said:
Couldn't tell you honestly. I don't use build.prop camera edits - mine are done in the media_profiles.xml located in /system/etc
Most edits in the build.prop so far have been disproved to do anything. I think at one time long ago Android may have used the build.prop for certain settings but now I think it's more or less just an info file for some programs to read. That way they know which settings to use, applications available, or information to display.
Not saying Crawj doesn't know what he's doing - he's a great dev. However we all know too well that old habits or ways of thinking die hard. Happens all the time with technology. Just my personal opinion.
Click to expand...
Click to collapse
ah i see which would explain why an init.d script supperceeds whats written in the build.prop...if both are trying to change the same value...so if i added those i guess they are called scripts (not sure if they have a different name than init.d) does it make a difference or do i need to remove them because of the uncertainty of if they are functional...i guess what im getting at is does extra clutter in the build.prop affect anything...
i think crarjs modified camera makes its changes in the media.profile like you mentiontioned... i found those tweaks and added them myself to see if they would do anything
do u make added anything your build.props or because of the actual functionality is uknown do u just not mess with it?
I just don't touch the build.prop at all since from what I've seen it does nothing. I will post my media_profiles.xml tomorrow for you to look at if you want but I don't know of any scripts to put in an init.d file. Doesn't mean there isn't some code out the to edit a property like the flash duration, intensity, and so on.
Sent from my SPH-D710 using XDA App
lets see, change dpi in build.prop, yep. Change vm heap size, yep, Im gonna say the other build.prop settings will work if entered correctly, and actually work on your phone model.
Sent from a phone with kNOw CIQ
TeamERA said:
lets see, change dpi in build.prop, yep. Change vm heap size, yep, Im gonna say the other build.prop settings will work if entered correctly, and actually work on the on your phone model.
Sent from a phone with kNOw CIQ
Click to expand...
Click to collapse
Of course those can also be set in an init.d file. What do you think the V6 and V8 scripts do? The numbers aren't magical, though I'm sure at times we've all thought so
The OP has understood it correctly - most things you change in the build.prop do absolutely nothing. Especially if they don't exist in our phone (see: hspa class). However, for the properties it can effect - well those are superseded by the init.d scripts or by any shell script.
EDIT: I also believe (not 100%, I'm not a dev) that most of the cameras properties as far a quality, resolution, file format, etc, are set in the .xml file. So entering anything contradicting what's in the .xml will be a waste of space just cluttering up your build.prop file and possibly increasing boot times.
well on that note i am going to remove what ever camera tweaks i added because as i already mentioned im using an already modified camera...and to be honest i just realized the values i added in the build.prop were already set and standard on the stock camera...so lord only knows what kind of confusion im causing lol
lunchboxVA said:
well on that note i am going to remove what ever camera tweaks i added because as i already mentioned im using an already modified camera...and to be honest i just realized the values i added in the build.prop were already set and standard on the stock camera...so lord only knows what kind of confusion im causing lol
Click to expand...
Click to collapse
Well here's that media_profiles.xml I told you about. Feel free to use it, I know some of the devs have made their own so I'm not taking credit. Mines actually a modified stock version made for potatomans tweaked camera. Just make sure to change the permissions (rw-r-r) and ownership of it after putting it in /system/etc if you do use it.
thank u...pardon the dumb question but how do i read it will it open in wordpad?
I would use notepad or download Notepad++ (it's free). The second option is probably the best but I've never really had an issue using the other.
I know its not new and i know that many roms+tweaks have it inside,but i think there are many users without any knowledge about this,so ive made this thread,please when anyone knows more than make a post here.!!!
----------------------------------------------------------------------------
how to:
1, Open "Root Explorer" and click the R/W
2, Go to /system/build.prop.
3,backup yout current build.prop.
4, Long-presson Build.Prop and you’ll see a pop up.
5, Text Editor.
6, Type in those few line of words below into the last line of the text then save.
7,reboot and enjoy.
Data Tweaks Increase download/upload/3G speeds:
ro.ril.hsxpa=1
ro.ril.gprsclass=10
ro.ril.hep=1
ro.ril.enable.dtm=0
ro.ril.hsdpa.category=8 (or 10,12,14) Still looking for more of these though.
ro.ril.enable.a53=1
ro.ril.enable.3g.prefix=1
ro.ril.htcmaskw1.bitmask=4294967295
ro.ril.htcmaskw1=14449
ro.ril.hsupa.category=6
POWER SAVES:
Allows the phone to sleep better
ro.ril.disable.power.collapse=1
Saves power when phone is sleep
pm.sleep_mode=1
Allows your wifi to scan less, saving more battery
wifi.supplicant_scan_interval=150 or 180 (your choice)
Helps Scrolling Responsiveness
windowsmgr.max_events_per_sec=150
Increase overal touch responsivenss
Debug.performance.tuning=1
Video.accelerate.hw=1
SYSTEM TWEAKS:
Forces your home launcher into memory
ro.HOME_APP_ADJ=1
Change the Dalvik VM heap size
dalvik.vm.heapsize=64m can use 24, 32 is default, 48, 64
To disable usb debugging popup
persist.adb.notify=0
Fix some application issues
ro.kernel.android.checkjni=0
Render UI with GPU
debug.sf.hw=1
These lines forces GPU&CPU to render graphics
debug.composition.type=gpu
debug.composition.type=cpu
_________________________________________________________________
I know there many others,so post it!!!Greeeeetz
RESERVED...
Lets make this thread to learn and discuss about tweak and function of tweak.. Advantage and disadvantage using tweak.. Which part cant running if only use 1 part of tweak.. etc
Its more helpfull than only share tweak without know what are they doing..
Ask permission to original tweak like stagmatis, adrenalin, kuro, etc tweak then discuss in this thread..
does this apply on stock or custom rom? I apologize im a noob
savie said:
Lets make this thread to learn and discuss about tweak and function of tweak.. Advantage and disadvantage using tweak.. Which part cant running if only use 1 part of tweak.. etc
Its more helpfull than only share tweak without know what are they doing..
Ask permission to original tweak like stagmatis, adrenalin, kuro, etc tweak then discuss in this thread..
Click to expand...
Click to collapse
thats the reason why ive posted that other peoples please share her expierence too on this thread.to freaks one idea,lol:good:
NEW STUFF AT THE BOTTOM
I have been looking into ways to make the touchscreen more responsive because I use light touches and sometimes the sensor goes crazy from them. Hopefully we can bring some project butter to ice cream sandwich.
Do a damn nandroid backup first so that if you have issues you can roll back. Don't be a fool, cause I pity tha fool!
THERE ARE NO BATTERY ISSUES REPORTED!
Works on Acro S, Ion, P, Xperia S, U. Please test it and let me know.
Under system/usr/idc there is a file called clearpad.idc
EDIT: Novathor Users (P,U,Sola) use this file instead synaptics_rmi4_i2c.idc
Edit this file with a text editor.
Touch pressure scale you want lower. I use .0001. THIS MAY CAUSE ISSUES IN SOME ROMS. Just try it out.
Needless to say, it seems to have made a difference in the sensitivity of the screen and also the buttons on the bottom.
Remember to make a backup of the file first.
After testing I am positive it does work, though it may be hard to tell. I do not see a difference between increasing the number to 1.0 or 5.0 so i use 1.0 right now.
The reason i did this is because back in the GB Xperia S days, one of the firmwares released had tweaks to this number which were for capacitive buttons. So I hunted down the file to find and change it.
Change clearpad.idc values to these.
touch.pressure.scale= 1.0 [instead of 0.0075]
Honestly its hard to tell the difference. If you set it to 0 it messes up tough input. The number is a scale factor multiplier so in theory a higher number would be equivalent to a higher pressure. So it would be better for quick soft touches, but if you want more accurate touching a smaller number would be better. Thats about all I can say. Just try it and see which one you like the best. 1.0 is default in android sdk
touch.size.scale= 20.00 [ instead of 16.91]
touch.size.bias= 70.00 [instead of 67.65]
Thanks to Auni for helping me confirm my suspicions
Here are some extra settings that help smoothness as well.
Change in the build.prop, if the lines arent there add them.
Easy to do in system tuner
UI Tweaks
Scrolling and Response
windowsmgr.max_events_per_sec=(240-300) pick one
ro.max.fling_velocity=12000
ro.min.fling_velocity=8000
View.scroll_friction=10
ro.kernel.android.checkjni=0
ro.kernel.checkjni=0
Data and Signals
ro.ril.hsxpa=3
ro.ril.gprsclass=12
persist.sys.ui.hw=1
Battery
ro.ril.disable.power.collapse=1
New Buildprop Tweaks Dalvik Specific
We have the sufficient memory for these so why not use it.
dalvik.vm.jniopts=forcecopy
dalvik.vm.execution-mode=int:jit
dalvik.vm.checkjni=false
dalvik.gc.type=precise
dalvik.vm.verify-bytecode=false
dalvik.vm.dexopt-flags=v=n,o=v,m=y
I am going to explain these under this. Heapstart size is the default size for an app memory usage upon start. If it needs more ram it will be allocated based on the growth limit. So if the app has 8 but needs more it initially gets more based upon the growth limit, but it will not exceed the heapsize which is the total limit for an apps memory usage. So like this HStart + HGrowth < or = HeapSize
These are optimal for our device-I may change these around as I test further
dalvik.vm.startheapsize=8m
dalvik.vm.heapgrowthlimit=64m
dalvik.vm.heapsize=128m (if you get apps closing because you the vm size is to small change this to 256)
Disable Logs
ro.config.nocheckin=1
Better Image Quality
persist.sys.use_dithering=1 (change to 0 if you want better performance)
Ram Usage
persist.sys.purgeable_assets=1 (this allows the system to free up more memory if it needs it. It might kill apps that are memory hungry)
Video Acceleration
debug.performance.tuning=1
video.accelerate.hw=1
Better Battery
ro.ril.disable.power.collapse=1
wifi.supplicant_scan_interval=100
ro.mot.eri.losalert.delay=1000
CLEAR THE DALVIK CACHE AFTER CHANGES!
NEW EXPERIMENTAL
CrossBreeder. Read the thread for details.
Flash this mod. It works damn good along with anything else.
http://forum.xda-developers.com/showthread.php?t=2113150
Follow the instructions, there are various ways to do this.
ICS ONLY
Edit:
V Sync Activator
This activates the v sync like what is used in jelly bean or on your PC.
http://www.mediafire.com/?iati95wju7sf77i
Does that increased or decreased the sensitivity?
Sent from my LT26i using Tapatalk
Felimenta97 said:
Does that increased or decreased the sensitivity?
Sent from my LT26i using Tapatalk
Click to expand...
Click to collapse
In theory it should increase the sensitivity because it is applying the standard amount to any touch pressure. At least this is what I have gleamed from the Android SDK. It feels more sensitive to me but I need some others to try to confirm it. Its easy to change back if it doesnt work.
definitely placebo..
tried it just now..
dont feel any difference..
Hmm it seems to work for me. Did you reboot?
Sent from hell using Xperia-S(atan)
I tried it. It seems to be more sensitive but I don't know it is whether an illusion. Need time to confirm.
Sent from my LT28i using xda premium
I'll try it, and I'll do some test using paper
Sent from my LT26i using xda app-developers app
Sorry, ot, but the best way to increase touch screen and buttons is to remove Sony pre applied screen protection
Sent from my Xperia S using xda app-developers app
ahvipardik said:
Sorry, ot, but the best way to increase touch screen and buttons is to remove Sony pre applied screen protection
Sent from my Xperia S using xda app-developers app
Click to expand...
Click to collapse
I already removed it, now im looking into increasing overall touch sensitivity. Im a tweaking fiend.
Is better if you explain in this way:
Find Under "system/usr/idc" a file called "clearpad.idc"
Edit in the file:
touch.pressure.scale = 0.0074
To
touch.pressure.scale = 5.0
Save the file and reboot the system
(Don't forgot to make a backup of the file)
Click to expand...
Click to collapse
I think this Mod work for me :laugh:
I'm now pretty sure it works
Sent from hell using Xperia-S(atan)
mrsatan said:
I'm now pretty sure it works
Sent from hell using Xperia-S(atan)
Click to expand...
Click to collapse
It works
Seems like it works for me too!
Sent from my LT26i using xda app-developers app
Just try it right now, I dont felt any change in the sensivity
To which numbers are you changed it?
Enviado desde mi LT26i usando Tapatalk 2
let's change it to 1000!
Sent from my LT26i using xda premium
It really is difficult to evaluate by contact with the screen.
But in relation to the buttons below it seems that improved!!
Sorry for bad english...
Im pretty sure it does work, but I am not sure anything above 1.0 works. I know that with this touchscreen type, 1.0 is default for the sdk. I havent noticed a difference between 5.0 and 1.0, but it certainly helps either way.
Chxrlyglez said:
To which numbers are you changed it?
Enviado desde mi LT26i usando Tapatalk 2
Click to expand...
Click to collapse
Read the op I updated the info.
mrsatan said:
After testing I am positive it does work, though it may be hard to tell. I do not see a difference between increasing the number to 1.0 or 5.0 so i use 1.0 right now.
Click to expand...
Click to collapse
so, I must change the touch pressure scale to 1.0? not 5.0?
As the title state. And please get it together & keep it clean, as this is kinda important to all.
Any help & explaination would be much apprecited.
Regards,
Sdojoin
I used to mess wit this on the X10, and did find better values. But for the Xperia Play, at least on CM10, any extra or changed flags either causes worse performance or FC's.
The defaults I use are:
Code:
dalvik.vm.dexopt-flags=m=y
Which means "Map registration = yes" (this should always be on) and everything else at default (what the ROM wants to do).
90% of what you need to know (and what is safe to experiment with) can be found in the DalvikVM documentation. Give it a good read.
Re: [Q][Disqus] "Dalvik.vm.dexopt-flag=???" - What are the best for performence
Thanks. But i was wondering if mybe we can "force" the system/rom to optimize the dalvik.vm each time we use it.
Example;
Code:
dalvik.vm.dexopt-flag=o=y,m=y(optimize=yes, register map=yes)
Or
Code:
dalvik.vm.dexopt-flag=o=v,m=y(optimize=verify,register map=yes)
Will it make any diff?? I know it'll use more ram than usual, but will it increase performence??
Regards,
Sdojoin
o=v (-Xdexopt:verified) is the default, as is v=a (-Xverify:all). This means that only opts that are verified will be optimized (cached to dex files). Unverified code will not be optimized.
Disabling verification will make dalvik-generation faster, but it is less safe and also 0% faster once the dalvik-cache is generated. Apparently it has the possibility of decreasing RAM usage at the expense of higher IO or CPU cycles (which wouldn't be bad, since RAM is the main limiting hardware on Xperia 2011 devices) but I never noticed any difference.
The only real change you can make there is o=a, which means that it will optimize *all* dalvik opts - even those that fail verification. In the case of custom ROM's, this usually results in constant FC's and even reboots - and can even make the system slower because some classes are intentionally made to fail verification when, in the development process that they were found to have overhead in dalvik-cache reading making the unverified cache slower than just reading reading the dalvik (compiled Java code) directly. This is usually the case with simple Java methods that are heavily dynamic and rarely used (e.g. on a service startup).
Another option can be v=n o=a which means to verify nothing and optimize everything (potentially the fastest but also unsafest).
With all this said, I have not tried messing with these things since Gingerbread. All I can say is, experiment with these flags. Measure the size of dalvik-cache, the time it takes to generate, and the time it takes to load a large dalvik app (look for an app/game that has a very large DEX file in dalvik-cache, measure different parts of the app/game loading sections since some parts might be native instead of dalvik/java).
Re: [Q][Disqus] "Dalvik.vm.dexopt-flag=???" - What are the best for performence
How exactly do i do that test??
Fyi, i already tried the v=n,o=a sett. It kinda denied su perm or mybe unroot my device. Coz i cant get any root app running & i hav to revert it back via flashable .zip. But like u said, its un-safe to use.
In-conclusion, "it can increase our perf & decrease it at the same time.". Erm...
Oh yeah, is it posible if i were to flag it like this??
Code:
dalvik.vm.dexopt-flag=m=o=y(map registration=Xdexopt=yes)
Just curious.
Regards,
Sdojoin
sdojoin said:
How exactly do i do that test??
Fyi, i already tried the v=n,o=a sett. It kinda denied su perm or mybe unroot my device. Coz i cant get any root app running & i hav to revert it back via flashable .zip. But like u said, its un-safe to use.
In-conclusion, "it can increase our perf & decrease it at the same time.". Erm...
Oh yeah, is it posible if i were to flag it like this??
Code:
dalvik.vm.dexopt-flag=m=o=y(map registration=Xdexopt=yes)
Just curious.
Regards,
Sdojoin
Click to expand...
Click to collapse
Nah, that makes no sense.
Read through this thread: http://forum.xda-developers.com/showthread.php?t=1622433
CosmicDan said:
Nah, that makes no sense.
Read through this thread: http://forum.xda-developers.com/showthread.php?t=1622433
Click to expand...
Click to collapse
Already read that actually.. I've already search & read through the web bout this still cant find any straight answer bout this. But then again there aren't any straight answer bout this, is there??
Another thing i would like to ask is bout vm.heapsize. Correct me if i'm wrong, the default value for all device is 32m, right?? And all my search state that 48m is the best value for both batt drain & perf. What do u think of that?? I really believe Play can do more & perform better in any case of situation. Dont matter either on stock or custom. Just need the right tweakin'.:fingers-crossed:
Well that first link I posted explains pretty much everything about the dalvik flags, and that thread I posted last is a good experiment for learning purposes. If it doesn't make sense I guess you need to know more about the Android technicals. But really, I think you can't wrap your head around it for one simple reason - there is no magical dalvik setting that will make the device faster. There is no "hidden setting" or "something Sony/FXP forgot to try" - the dalvik settings are fine, and while changing them may slightly increase performance in *some* cases, it will almost always reduce reliable and performance in other cases.
About dalvik heapsize:
The dalvik.vm.heapgrowthlimit property limits how large an Android application’s heap can get before garbage collection has to be attempted. The dalvik.vm.heapsize property defines an absolute maximum for the heap size for an application even when the largeHeap flag is set in the manifest. Google’s motivation behind doing this was clearly to limit the heap size to a reasonable amount for most applications, but also give some flexibility to app developers who know they’re going to need the largest heap size possible to run their application.
Should you change this setting? Probably not. The ICS default for a phone with (at least) 1024MB of RAM is 64m. You can check your specific phone’s value as the hardware vendor can override this themselves when they build the ROM. But don’t let the disparity between 1024 and 64 bother you; most mobile apps should not have any problems with 64MB of heap size unless the developers are naughty. When this limit is reached, a garbage collection routine will remove obsolete objects from memory reducing the heap size down considerably in most cases. It is extremely unlikely raising this value to reduce GC routines will have any perceptible effect. If anything, it could cause other apps or the general system to suffer from too many stale objects sulking around in memory. Garbage collection will inevitably occur either way, and when it does, the size of the heap will likely have a direct impact on the cost of the routine.
The point is, it is impossible for a user to optimize for every application using this system-wide setting. This responsibility falls on application developers to optimize their applications, not users. The largeHeap flag was created to allow developers to do just that. If you do feel compelled to experiment with this setting regardless, be mindful that an application could have up to two heaps at once. Thus, the heap growth limit value should always be, at most, a little less than half of the maximum allowable heap size.
Click to expand...
Click to collapse
In summary - heapsize = memory an app can consume before Android starts cleaning/pruning the app's memory for data that isn't in use. Lowering it to e.g. 40m can increase performance a bit but some games fail to load (because the OS starts GC when the app has not finished using the heap it requires; and also because so many game developers out there are lazy and don't do threaded asset loading properly)
Re: [Q][Disqus] "Dalvik.vm.dexopt-flag=???" - What are the best for performence
Hmm... Quite a mouthfull. Imma try & digest it slowly just so i could grasp everything properly.
A side Q, the 40m example u gav, does that really help?? I'm on GB btw. Only went to ics or jb when i got free time to test.
Do u recommend that example to be use or do u hav any other recommendation that would probably help me & other that read this thread??
Regards,
Sdojoin
Re: [Q][Disqus] "Dalvik.vm.dexopt-flag=???" - What are the best for performence
Experiment and see as long as you make backups, nothing can possiblii go wrong.
Sent from Xperia Play (R800a) with Tapatalk
Re: [Q][Disqus] "Dalvik.vm.dexopt-flag=???" - What are the best for performence
Right on. Thanks for ur time & for sharing ur experience & everything.
Salute.
Regards,
Sdojoin
No problem. Let me know if you find anything interesting. But you are on GB and I'm on JB, still I don't have much time to mess with this stuff - especially now that my linux machine is back in action
Re: [Q][Disqus] "Dalvik.vm.dexopt-flag=???" - What are the best for performence
Woo.. Guess we can expect smething new from ya?? And i think i found smthing thats kinda weird or mybe interesting. After i disable the bytecode verifier, any heapsize that i put on build.prop dosent stick. And when i run this code on terminal,
Code:
getprop dalvik.vm.heapsize
It always came up with the same value. So i decided to use that value instead. I dont know if its the best value or not. But it does shows slight improvement. I havent try any games yet. Hopefully it perform a bit better than be4.
Regards,
Sdojoin
Hey,
These have seemed to improve performance (mainly boot time and app loading) on Gingerbread. They are set in new Turbo UI Classic ROM, give them a try.
Code:
# was m=y
dalvik.vm.dexopt-flags=m=y,v=n,o=v,u=n
TBH, I really don't know a lot about how the dalvik flags tie together. But this seems to work well and stable.
CosmicDan said:
Well that first link I posted explains pretty much everything about the dalvik flags, and that thread I posted last is a good experiment for learning purposes. If it doesn't make sense I guess you need to know more about the Android technicals. But really, I think you can't wrap your head around it for one simple reason - there is no magical dalvik setting that will make the device faster. There is no "hidden setting" or "something Sony/FXP forgot to try" - the dalvik settings are fine, and while changing them may slightly increase performance in *some* cases, it will almost always reduce reliable and performance in other cases.
About dalvik heapsize:
In summary - heapsize = memory an app can consume before Android starts cleaning/pruning the app's memory for data that isn't in use. Lowering it to e.g. 40m can increase performance a bit but some games fail to load (because the OS starts GC when the app has not finished using the heap it requires; and also because so many game developers out there are lazy and don't do threaded asset loading properly)
Click to expand...
Click to collapse
Ther is one thing i don't understand: the default values of the Nexus 7 are:
dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=64m
dalvik.vm.heapsize=384m
Especially the heapsize seems to be very high.
The defauklt settings of my Galaxy Note with CM10.1 are:
dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=48m
dalvik.vm.heapsize=128m
So they are much lower values. Bothe devices have 1Gb of Ram.
Some people say higher=better, some say lower=better and I'm really confused now.
What are the "perfect" values for the Galaxy note (1GB Ram) or Note 2 (2GB Ram) ?
I hope somone can explain me these things :fingers-crossed:
xxLeoxx93 said:
Ther is one thing i don't understand: the default values of the Nexus 7 are:
dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=64m
dalvik.vm.heapsize=384m
Especially the heapsize seems to be very high.
The defauklt settings of my Galaxy Note with CM10.1 are:
dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=48m
dalvik.vm.heapsize=128m
So they are much lower values. Bothe devices have 1Gb of Ram.
Some people say higher=better, some say lower=better and I'm really confused now.
What are the "perfect" values for the Galaxy note (1GB Ram) or Note 2 (2GB Ram) ?
I hope somone can explain me these things :fingers-crossed:
Click to expand...
Click to collapse
There never exist "perfect values for dalvik".
It is how you want to allocate memory.
1. VM Heap Size is max Memory per one ram heal that can be given to an app.
2. Heapstartsize is the minimum size for a dalvik ram heap.
3. HeapGrowthLimit is a value for "normal" VM heaps, I reccomend setting VM heap size large and then HeapGrowthLimit at a good value.
Sent from my GT-I9300 using xda app-developers app
CosmicDan said:
Hey,
These have seemed to improve performance (mainly boot time and app loading) on Gingerbread. They are set in new Turbo UI Classic ROM, give them a try.
Code:
# was m=y
dalvik.vm.dexopt-flags=m=y,v=n,o=v,u=n
TBH, I really don't know a lot about how the dalvik flags tie together. But this seems to work well and stable.
Click to expand...
Click to collapse
Already tried n went back to m=y. It kinda hung up on some app that make'em fc. A diff sequence mybe??
Regards,
Sdojoin
sewer56lol said:
There never exist "perfect values for dalvik".
It is how you want to allocate memory.
1. VM Heap Size is max Memory per one ram heal that can be given to an app.
2. Heapstartsize is the minimum size for a dalvik ram heap.
3. HeapGrowthLimit is a value for "normal" VM heaps, I reccomend setting VM heap size large and then HeapGrowthLimit at a good value.
Sent from my GT-I9300 using xda app-developers app
Click to expand...
Click to collapse
No it's not. All the heapsize parameters are to do with GC, they have nothing to do with "how much memory" dalvik tasks will use but determine barriers/zones for garbage collection.
Besides, if you read the therad you'd see that this has nothing to do with what we're talking about. We're talking on *flags*, heap parameters should NEVER be changed and will only make device unreliable.
EDIT: Read documentation before repeating what others say on the internet - http://show.docjava.com/posterous/file/2012/12/10222640-The_Dalvik_Virtual_Machine.pdf
sdojoin said:
Already tried n went back to m=y. It kinda hung up on some app that make'em fc. A diff sequence mybe??
Regards,
Sdojoin
Click to expand...
Click to collapse
Hmm fair enough. Well I've only ever seen m=y on any ROM, stock or custom or otherwise (as long as it hasn't been screwed up by some idiot chef). So maybe it's just a case as most so-called tweaks - what it comes with is what it's designed to work with.
Perhaps with the Qualcomm-accelerated Dalvik blobs (I posted it a while back, check my threads) there will be different results.
sdojoin said:
Already tried n went back to m=y. It kinda hung up on some app that make'em fc. A diff sequence mybe??
Regards,
Sdojoin
Click to expand...
Click to collapse
have you delete dalvikcache and reboot on every change?
mpjoe2000 said:
have you delete dalvikcache and reboot on every change?
Click to expand...
Click to collapse
Same.. Thats y its weird.
@CosmicDan - can u giv the thread link?? Thx
Regards,
Sdojoin
Ok - you may be familiar with my mod here -
http://forum.xda-developers.com/hon...ipt-disable-enable-swap-honor-5x-kiw-t3308321
If not - try it - but in any case, from that thread, get SH Script Runner, Stericson's Busybox Installer
What this mod is about -
Makes your phone act like it's 720p instead of 1080p
It's still 1080p
But it moves the work from the GPU to the screen's hardware scaler
There's no such thing as a free lunch so this won't give you more battery duration
This may screw up your favorite keyboard, like SwiftKey - use the Google keyboard
This may screw up your icon sizes in your launcher (so look for launcher options to change that if you care)
This is going to make your fonts smaller in many places
This mod is not guaranteed to work the way you want
You MUST make a nandroid backup before proceeding if you know what's good for you
Run this the same way as you would my swap scripts
What this mod contains -
dpi-switch.zip that you unzip at the top of your /sdcard
If you followed the swap script instructions, you already knew that
720p.sh does exactly what the name implies - it's the mod
1080p.sh does what the name implies - it restores your phone to the default state
You must be root to run - see the instructions - turn on the SU button in SH Script Runner
Your phone will reboot when done
I may or may not change that
What could possibly go wrong -
If you use this with other DPI or screen mods, the sky could fall, your friends will leave and your dog will disown you - plus your phone will be borked
You didn't ignore me, you made a nandroid backup so nothing really bad can happen if you did
The screen may start out as tiny - play with it some, it will sort itself out - maybe even hold power to kill it and start it again
I can reproduce that but not every time
You can get the right sized screen and be fine, just play with it if it hits you
Try turning to landscape and back, that seems to clear it up too
That only happens right after the mod is applied
Important things to know about this mod -
No puppies were harmed during its creation
I am not responsible if your phone dies, catches fire, blows up, tries to take over the world, or starts running like a bat out of hell and makes you very happy
OK, I'm a little bit responsible for that last bit but only a little
Monjori OpenGL Shader benchmark test - 49 fps stock, 62 fps modded
PERFECTLY SAFE TO GO BACK AND FORTH FROM 720 TO 1080 AT ANY TIME
Enjoy - if it's pretty necessary, I'll come back with pictures - but seriously - see the swap thread linked about - this just copies the same approach, and just gives you some new commands.
Cheers!
PS - Yes - you can too do this yourself or use some other apps. No - nothing is as easy as doing it this way if you're not an expert in these things - that's why I made this for you.
Download is right here -
View attachment dpi-switch.zip
Here are the codes:
720p -
Code:
#!/system/bin/sh
# Sets 720p windows defaults on 1080p 5.5" Huawei, such as honor 5x
# Must run as root
# WILL reboot when finished!
# March 19, 2016
# EarlyMon
wm size 720x1280
wm density 320
setprop sys.powerctl reboot
1080p -
Code:
#!/system/bin/sh
# Restores 1080p windows defaults on Huawei, such as honor 5x
# Must run as root
# WILL reboot when finished!
# March 19, 2016
# EarlyMon
wm size reset
wm density reset
setprop sys.powerctl reboot
Is it the same as running
adb shell wm size 720x1280
adb shell wm density 320
adb reboot
Through adb or are there changes in value ?
Edit: I looked into the files and saw a change in density, 267 instead of 320...would it work with 320 ?
Zakaria.R said:
Is it the same as running
adb shell wm size 720x1280
adb shell wm density 320
adb reboot
Through adb or are there changes in value ?
Edit: I looked into the files and saw a change in density, 267 instead of 320...would it work with 320 ?
Click to expand...
Click to collapse
Yep, basically the same thing. There are namespace and zygote differences from Huawei so things in a terminal emulator aren't always the same as when run through adb, so we need root here.
267 comes from Pythagoras -
sqrt( 720^2 + 1280^2 ) / 5.5 = 267
320 is the class value understood by services and both work equally well.
I've updated the script to the use the 320 class value for density and went ahead and changed shutdown to reboot - I've seen occasional weirdness with just a reboot, but the first post instructions say if it's weird, try a shutdown anyway.
I'm not sure the changes make a difference but you're right - most folks familiar with this will expect the class value there, so I've changed the script.
And as I mentioned at the end of the post - no magic, nothing you can't do yourself if you know how, just a lot easier this way for non-experts.
Cheers!
PS - added the script codes to the second post, no secrets to this.
EarlyMon said:
Yep, basically the same thing. There are namespace and zygote differences from Huawei so things in a terminal emulator aren't always the same as when run through adb, so we need root here.
267 comes from Pythagoras -
sqrt( 720^2 + 1280^2 ) / 5.5 = 267
320 is the class value understood by services and both work equally well.
I've updated the script to the use the 320 class value for density and went ahead and changed shutdown to reboot - I've seen occasional weirdness with just a reboot, but the first post instructions say if it's weird, try a shutdown anyway.
I'm not sure the changes make a difference but you're right - most folks familiar with this will expect the class value there, so I've changed the script.
And as I mentioned at the end of the post - no magic, nothing you can't do yourself if you know how, just a lot easier this way for non-experts.
Cheers!
PS - added the script codes to the second post, no secrets to this.
Click to expand...
Click to collapse
Appreciate the explanation good job my friend keep up
Performance Impact for 2D games
I notice my phone is bit laggy when I play 2D game with 720p mode. I doubt scaler is overloaded.
So I compare both score with GFX benchmark.
Here are texturing results. 720p score was about 1270, native was about 1400.
720p mode impact some 2D performance by use hardware scaler always.
Same benchmark shows improvement in other areas - there's no simple answer and this is a mod to use when it benefits games that get along with it. As you've found, not all do.
EarlyMon said:
Same benchmark shows improvement in other areas - there's no simple answer and this is a mod to use when it benefits games that get along with it. As you've found, not all do.
Click to expand...
Click to collapse
Strong agree.
I decided my phone to leave default. 'cause for me, more suitable than 720p. But someone is not.
Not simple.
Here are all results for comparison. for someone.
On my KIW-L21 the Screen did not scale, unfortunately.
Meaning the Screen with a resolution of 720p was stuck in the upper left corner of the screen(Like a window, the rest of the screen was black),
while the touch input was rooted from the whole screen, which made it a little bit challenging to operate the device
Any idea how one could tackle that problem?
Nekly said:
On my KIW-L21 the Screen did not scale, unfortunately.
Meaning the Screen with a resolution of 720p was stuck in the upper left corner of the screen(Like a window, the rest of the screen was black),
while the touch input was rooted from the whole screen, which made it a little bit challenging to operate the device
Any idea how one could tackle that problem?
Click to expand...
Click to collapse
1. Enable auto-rotate. Then rotate your phone at lock screen.(See #1)
2. Try edit script "wm density 267" instead of 320. Use SH script runner on root mode. (See #3~)
3. Try adb command via PC (see #3) if you feel too difficult to operate with touch screen.
I counter same problem. I resolve this with 3. 'cause I can't unlock my phone
ssrnsrsr said:
1. Enable auto-rotate. Then rotate your phone at lock screen.(See #1)
2. Try edit script "wm density 267" instead of 320. Use SH script runner on root mode. (See #3~)
3. Try adb command via PC (see #3) if you feel too difficult to operate with touch screen.
I counter same problem. I resolve this with 3. 'cause I can't unlock my phone
Click to expand...
Click to collapse
1. Autorotate is on. Does not do anything.
2. Edited the script to uses 267 density. Did not work either.
3. ADB kinda works with density 320. I could test, wether to use this mod or not. But in my Use Case I got no benefit whatsoever. Also not beeing able to change this on the go is another deal breaker to me.
Thanks for the support.
I have the same results as Nekly. After digging deeper, the problem lies within the EMUI 3.1 launcher. After you change the resolution/density, the icons look all jacked. I opened some games, and the games look just fine. There is definitely a noticeable FPS boost.
There's no such thing as a free lunch so this won't give you more battery duration
Click to expand...
Click to collapse
After careful thought, I tend to disagree with this statement. While the screen is off, hes right, there is no free lunch there. While I have not tested it, in theory it *should* result in more battery duration while you are using the phone. My theory is that if you were to change the resolution to 720x1280 thats 921600 total pixels rendered on the screen. Instead of the normal 1080x1920 which is 2073600 total pixels rendered. Thats a net difference of 1161000 less pixels that the GPU has to render. So less work for the GPU. The MHZ will still be the same so no change there. If there was no FPS boost in the game, then the GPU would still be doing the same amount of work. But there is an FPS boost.
This is an awesome tweak, I wish I could get the launcher to display the icons correctly. Again great work @EarlyMon!
TouchOdeath said:
I have the same results as Nekly. After digging deeper, the problem lies within the EMUI 3.1 launcher. After you change the resolution/density, the icons look all jacked. I opened some games, and the games look just fine. There is definitely a noticeable FPS boost.
After careful thought, I tend to disagree with this statement. While the screen is off, hes right, there is no free lunch there. While I have not tested it, in theory it *should* result in more battery duration while you are using the phone. My theory is that if you were to change the resolution to 720x1280 thats 921600 total pixels rendered on the screen. Instead of the normal 1080x1920 which is 2073600 total pixels rendered. Thats a net difference of 1161000 less pixels that the GPU has to render. So less work for the GPU. The MHZ will still be the same so no change there. If there was no FPS boost in the game, then the GPU would still be doing the same amount of work. But there is an FPS boost.
This is an awesome tweak, I wish I could get the launcher to display the icons correctly. Again great work @EarlyMon!
Click to expand...
Click to collapse
0.5 × 2 = 1
If you render half as many pixels per frame but increase the number of frames per second by what could be a factor of two, then the system theoretically ends up rendering the same number of pixels per second.
(pixels/frame × frames/second = pixels/second)
GPUs and displays work on fields - even the LCD control matrix doesn't have to refresh in terms of pixels - so the math is actually quite a bit more complex for making predictions.
If you get better battery performance, great!
But I won't promise that because TANSTAAFL.
Nice!! Very deep insight, love the formula!!
Loving these small but useful script contributions, Mon. Thanks for the hard work. Will definately try this when I get home. Question - is the effect on the icons on the native launcher only? I removed that from /system and installed Nova as my only and default launcher, so just wondering if it's Huawei's fault or just a secondary effect from the resolution change.
I have the same results as Nekly. After digging deeper, the problem lies within the EMUI 3.1 launcher. After you change the resolution/density, the icons look all jacked.
Click to expand...
Click to collapse
What I said in the above quote is wrong. Nekly does a great job in describing the problem:
On my KIW-L21 the Screen did not scale, unfortunately.
Meaning the Screen with a resolution of 720p was stuck in the upper left corner of the screen(Like a window, the rest of the screen was black),
while the touch input was rooted from the whole screen, which made it a little bit challenging to operate the device
Any idea how one could tackle that problem?
Click to expand...
Click to collapse
I'm experiencing the exact same problem on my L24 as @Nekly and I now have a ghetto solution.
There is an app called Resolution Changer. It has widgets you can place on your desktop. I have two widgets, a 720p and a 1080p. When the device is rebooted, the resolution will screw up, all you have to do is click on the 1080p, and it will restore fullscreen. Then click on 720p widget, and your screen will be fullscreen 720p. I'll post a better solution when I find one.
+1 to @EarlyMon for coming up with this geniusry. This tweak is clutch.
Can anybody get me a flashable zip that resets the resolution back to 1080p? I used the Resolution Changer app and somehow I screwed up my display. Any help would be appreciated!
EDIT: found this -->https://forum.xda-developers.com/android/general/guide-fixing-resolution-using-nomone-t2921856, this guy saved my day, but it would be more convenient when having a flashable zip file instead of having to connect to a computer and reset res via adb. Cheers!:good: