[anon(235100)]

I came across some random posts on xda from a few phones- one of them being a recent discussion for the LG P500 about a few file & build.prop tweaks to boost 3D performance. I don't normally use benchmarks as proof, or post about them, but the scores for 3D did go up about 100 points for me after making these changes. Plus, tested on Deer Hunter 3D and Apparatus & it is possibly smoother though I haven't played those games in a while.
Anyways, here's the changes:
BACKUP!
delete /system/lib/egl/libgles_android.so
chmod to edit /system/lib/egl/egl.cfg
and remove 1st line (just leave the adreno line)
chmod back to original permissions for egl.cfg

edit build.prop

debug.sf.hw=1
debug.composition.type=gpu
ro.secure=0
windowsmgr.max_events_per_sec=280
debug.performance.tuning=1
video.accelerate.hw=1
dalvik.vm.verify-bytecode=false
dalvik.vm.dexopt-data-only=1
persist.android.strictmode=0
ro.min_pointer_dur=1

wipe dalvik & reboot

I don't know who originally came up with this but here's a thread some guy put together on xda [tweak] improve 3d performance of lg p500 - updated - xda-developers

As far as I know it works on Gingerbread but I'd let the devs test if they're curious to see if it makes magic happen.

At 1st I did the delete file & edit the config file part but didn't notice much. Then I came across that post which mentioned the prop tweaks and that bumped up the Quadrant scores at that point.

My guess is it's forcing the phone to use the Adreno libs & gpu rendering- blah blah blah. I'm a techie but not too technical.

I don't know the affect on battery life but I'd assume if it's removing software rendering and just using GPU (hardware) rendering it'd save battery. Again, I'm not that technical.

[arnold1997]

should we follow the instructions at xda or the ones you suggest ?
lol have you tried it?

Edit*** My bad i didnt fully read..

[anon(235100)]

Yes. I've tried it for the past few hours without probs. My instructions are basically the same as his, though I'd stick with the adreno libs already on your device.
if you're going all command line I'd probably need to add some notes on the chmod & build.prop part.

make a backup 1st!
connect your phone & adb shell
mount -o remount,rw -t yaffs2 /system /system
mv /system/lib/egl/libgles_android.so /sdcard/
chmod /system/lib/egl/egl.cfg to something writable if it isn't
vi /system/lib/egl/egl.cfg
remove the 1st line (says something like '0 0 android'. leave the adreno line or I'm pretty sure you'd get a black screen or your phone would bootloop or something)
chmod /system/lib/egl/egl.cfg back to it's original permissions I guess

out of adb shell run adb pull \system\build.prop c:\

add those lines in the build.prop (if any are already there change those values)
adb push c:\build.prop \system\

reboot into recovery & flush the dalvik cache
after that reboot. It'll take a while this reboot since you flushed the dalvik cache

if those commands don't work I'm just typing them as I post. I ran through it once since I'd made a backup 1st so if I effed things up I'd be able to recover.

[anon(235100)]

I'll report back if my phone explodes. So far so good.

[arnold1997]

I'll report back if my phone explodes. So far so good.

Same here it works pretty well

Sent from my LG-VM670 using Android Central Forums

[LeslieAnn]

video.accelerate.hw=1

Much of the build prop gets over-written on boot by stuff in the boot.img. Wifi suplicant scan is useless in the build prop, at least on Froyo, but most likely on GB as well.

Video acceleration on the other hand, I beleive enables stagefright and will work from the build.prop. Unfortunately while you will see a benefit on home screens and many other things, it also causes a TON of video rendering issues.

There was also a lot of discussion about whether or not this actually was beneficial in most cases.

[A.I.]

This doesn't do too much exactly. Deleting the .so file simply removes software rendering in 3D applications. There is a bug to where Adreno GPUs are bugged in the sense that some OpenGL supports isn't reported so it falls back on software. You won't notice much in CM7.

The rest of the build prop edits mix in slight performance boosts (dalvik ones) to just sensitive scrolling (tuning line).

Max events makes thing seem smoother but its already high in IHO. In fact, some of those lines are already in the default build.prop for IHO ROMs.

[anon(235100)]

Max events makes thing seem smoother but its already high in IHO. In fact, some of those lines are already in the default build.prop for IHO ROMs.

I saw 2 of those lines in the IHO ROM. That tuning one and one other. I agree that tuning one is probably not necessary since its already close to that number anyways.


Critiques don't hurt my feelings-esp. since I just played with something I read earlier tonight in fact, I'd probably not do all of this again because I'll end up flashing again in a week and I don't want to add more junk to my i-need-to-do-this-this-and-this repetoire after each Rom flash.
If it gets scrutinized and added to a Rom because it does something-great. If not, no skin off my butt.

[anon(235100)]

Much of the build prop gets over-written on boot by stuff in the boot.img. Wifi suplicant scan is useless in the build prop

When I use setprop from adb- yes, they didn't survive a reboot. But when I did an adb pull, edited the file and pushed it back it does stay as I left it.
Also, I never mentioned wifi supplicant scan interval?


My question is where do these people come up with random build.prop changes anyways? I mean is there some reference of unused settings or are they just making them up? I think I'm going to make one for ludicrous speed and see what it does