I think we should also revisit keyodi's suggestion here (http://xdaforums.com/showthread.php?p=22277804#post22277804) - a few people reported good results with that change. Any more feedback? Or is it just a placebo effect?
I've been getting freezes but I hadn't been aware of that change. I'll give it a go and see if it makes a difference.
edit: That was quick. Got a freeze in the same spot I often do. After I close a game and go back to the app drawer it seems like it will frequently freeze when I scroll between screens.
Last edited:
Same here (though I must confess I'm new at this)
-wipe cache + data
-updated to 3/3 + gapps
-system seem to be slow and gotten one hang
-reflashed and supercharged as instructed here
-System seems more stable and slick, though I have been getting quite a few lockups. It seems they occur when I'm switching in or out of tasks, rather than staying put.
I upgraded to 3/3 this morning on my SANDISK SD card.
2 freeze ups so far and it is running really slow.
This is a test SD card and the only thing I have on it is the gapps stuff plus DOLPHIN HD and FLASH. Video via the browser (in CNN Video) plays when it wants and is horribly slow.
2 freeze ups so far and it is running really slow.
This is a test SD card and the only thing I have on it is the gapps stuff plus DOLPHIN HD and FLASH. Video via the browser (in CNN Video) plays when it wants and is horribly slow.
Posting my cross-link to the ICS thread from Dalingrin. http://xdaforums.com/showpost.php?p=23249779&postcount=2033
In this, I explain that I do receive positive results using Keyodi's suggestion every time. I'm more than certain that it's not a placebo and should be considered as an addition for the default configuration in the OpenGL builds.
Seperately, I also wanted to note that the latest build you created has gone a long way to resolve stability issues. At a review of what had changed, you can see in my post that I point that it's likely related to the Javadoc fix by Steve (who continues to astound in CM even with his new job
).
The 3-1 and 3-3 builds still didn't have that merged code yet, so it'll be interesting to try from 3-4 onward for those that had enough instability that it was difficult to determine if Keyodi's suggestion had impact.
I also mention my memory configuration settings using the stock OpenGL builds.
In this, I explain that I do receive positive results using Keyodi's suggestion every time. I'm more than certain that it's not a placebo and should be considered as an addition for the default configuration in the OpenGL builds.
Seperately, I also wanted to note that the latest build you created has gone a long way to resolve stability issues. At a review of what had changed, you can see in my post that I point that it's likely related to the Javadoc fix by Steve (who continues to astound in CM even with his new job
).The 3-1 and 3-3 builds still didn't have that merged code yet, so it'll be interesting to try from 3-4 onward for those that had enough instability that it was difficult to determine if Keyodi's suggestion had impact.
I also mention my memory configuration settings using the stock OpenGL builds.
Last edited:
Might want to also limit the background processes to 2 or 3... I find that the standard background processes eat the battery and also slow it down a lot...Posting my cross-link to the ICS thread from Dalingrin. http://xdaforums.com/showpost.php?p=23249779&postcount=2033
In this, I explain that I do receive positive results using Keyodi's suggestion every time. I'm more than certain that it's not a placebo and should be considered as an addition for the default configuration in the OpenGL builds.
Seperately, I also wanted to note that the latest build you created has gone a long way to resolve stability issues. At a review of what had changed, you can see in my post that I point that it's likely related to the Javadoc fix by Steve (who continues to astound in CM even with his new job
The 3-1 and 3-3 builds still didn't have that merged code yet, so it'll be interesting to try from 3-4 onward for those that had enough instability that it was difficult to determine if Keyodi's suggestion had impact.
I also mention my memory configuration settings using the stock OpenGL builds.
I think one of the problems with V6 is.. we don't have 512 mb of avalible ram... So the aggressive profile is bordering on limiting all functionality of the device.. Hense why i recommend 6 (or even 5)...
Update running 3-4 with V6 (option 6) and Keyodi's suggestion on removing the 0 0 Android line...
Also switched to 600-1200 with conservative gov. (just for the time being) and already noticing a much faster rotation (landscape to portrait and back) transition.. Was very sluggish on previous builds and it takes about 1/2 the time (still a second or two) for it to attempt to make the transition...
Last edited:
Thanks! I'd missed that setting as it's not sticky in "Developer Options". However, if I reboot and will remember to check it, I do see the benefit.
Currently I'm looking for the corresponding build.prop entry to add to fix that setting.
While in "Developer Options", have you tried the Windows and Transition animation scales changed to .5x?
Once I find the entry for fixing the setting for background process limits in build.prop (if that option does exist), I'll come back and update this post.
That speeds up the animation which is fine.. what i am referencing is a sensor lag tho... The time between you switching it into another mode and the sensor triggering the action to occur.
Anyone tried these?
# Render UI with GPU
debug.sf.hw=1
# Increase overall touch responsiveness
debug.performance.tuning=1
video.accelerate.hw=1
Don't we have video acceleration with opengl?
Strange... the build.prop has wifi.supplicant_scan_interval = 30
This seems like a very short time and could be leading to battery drain with wifi on.. correct?!?
But then v6 sets wifi.supplicant_scan_interval = 180
Any idea which one is the one that will set? Think i am going to delete the =30
Also in buildprop
Dalvik.vm.heapsize=256m ... That can't be right.. Shouldn't it be 48m since growthlimit is set to 48m?!?
Last edited:
Yes, unless something is merged in that hour, then it will make it to the 0800 build.
I'm running a tnp build (20120220-tnp), and I've been having a problem updating ever since I installed it. I just installed both of this morning's eyeballer builds, and latest gapps (20120304), and I get a complete lockup after Android starts up.
The installs this morning went: wipe both caches, format /system, install system zip, install gapps, go. Both played the (cropped) bootanim, "optimized" my apps, then went into the lock screen. After that, my NC locks up completely with the screen on. The clock doesn't update, no touches appear to register, short press on power does nothing, unplugging the cable doesn't turn off the charging icon. It does connect to the local WiFi. I might get a few notifications (usually ClockSync), I might not. While it's "optimizing", touches appear to register; I have "show touches" enabled, it's very instructive, esp. when the screen gets wet or dirty!
I get the same behavior with tnp's last build, 20120225-tnp-emmc.
Any ideas? I can reflash 20120220-tnp as above and all is well. Does anybody know if that build leaves some settings that kill the later builds? Can I wipe settings without a complete data wipe? Have I missed a setup step somewhere?
I have set CPU to 600-1200 interactivex. I've deleted all of my superuser allows and I'll see what happens next, but I'm at work, and there's stuff to do...
Thanks for any help!
The installs this morning went: wipe both caches, format /system, install system zip, install gapps, go. Both played the (cropped) bootanim, "optimized" my apps, then went into the lock screen. After that, my NC locks up completely with the screen on. The clock doesn't update, no touches appear to register, short press on power does nothing, unplugging the cable doesn't turn off the charging icon. It does connect to the local WiFi. I might get a few notifications (usually ClockSync), I might not. While it's "optimizing", touches appear to register; I have "show touches" enabled, it's very instructive, esp. when the screen gets wet or dirty!
I get the same behavior with tnp's last build, 20120225-tnp-emmc.
Any ideas? I can reflash 20120220-tnp as above and all is well. Does anybody know if that build leaves some settings that kill the later builds? Can I wipe settings without a complete data wipe? Have I missed a setup step somewhere?
I have set CPU to 600-1200 interactivex. I've deleted all of my superuser allows and I'll see what happens next, but I'm at work, and there's stuff to do...
Thanks for any help!
Added:
# Render UI with GPU
debug.sf.hw=1
# Increase overall touch responsiveness
debug.performance.tuning=1
video.accelerate.hw=1
To my build.prop and the UI is much faster and smoother (only 3/4 with opengl and the 0 0 android removed)... Only problem.. I scrolled thru my app drawer way to fast back and forth and caused the nook color to reboot lol.....
# Render UI with GPU
debug.sf.hw=1
# Increase overall touch responsiveness
debug.performance.tuning=1
video.accelerate.hw=1
To my build.prop and the UI is much faster and smoother (only 3/4 with opengl and the 0 0 android removed)... Only problem.. I scrolled thru my app drawer way to fast back and forth and caused the nook color to reboot lol.....
Last edited:
Numus,
You likely have been referencing thread that I also have used for build.prop, etc, referencing.
http://xdaforums.com/showthread.php?t=1227269
In that one, the supplicant timeout is set much higher than from SuperCharger, so 180 shouldn't be an issue. Guess some are using 7 minutes. The only disadvantage I would see is if you are in an environment would be with multiple networks and are roaming between them. With a large value, it would be possible to loose connection to one Wireless connection and wait before it discovers the new one during the scan 3 minutes later.
As for the rapid scrolling leaving you a locked up Nook, perhaps the following setting is something to try experimenting with.
It's item #6 on the thread I posted.
windowsmgr.max_events_per_sec=150
You likely have been referencing thread that I also have used for build.prop, etc, referencing.
http://xdaforums.com/showthread.php?t=1227269
In that one, the supplicant timeout is set much higher than from SuperCharger, so 180 shouldn't be an issue. Guess some are using 7 minutes. The only disadvantage I would see is if you are in an environment would be with multiple networks and are roaming between them. With a large value, it would be possible to loose connection to one Wireless connection and wait before it discovers the new one during the scan 3 minutes later.
As for the rapid scrolling leaving you a locked up Nook, perhaps the following setting is something to try experimenting with.
It's item #6 on the thread I posted.
windowsmgr.max_events_per_sec=150
Naa i was referencing from the google documents but it is the same thing in the end..
Our wifi supplicant was set to 30 seconds (which if you dont have wifi sleep policy turned on can eat the battery a lot)... V6 implemented a 180 but it didn't delete the 30.. So i had 2 entries for wifi supplicant. I deleted the 30 second one and left teh 180 second..
I also enabled hardware acceleration and rendering of the ui by the gpu.. it made it much snappier... Will try changing the max events per second...
V6 also set windowsmgr.max_events_per_sec=200... just dropped it down to 150
Also dropping VMheapsize from 256m to 48m ...
I would recommend you try those in your buildprop and let me know what you think.
Last edited:
Stolen moment: wipe cache & dalvik
Using today's build and the latest g-apps :
Everything seems much snappier. Only thing I noticed is a FC while playing "Words with Friends" (after making a move then backing out of the advertisement)
Sent from my NookColor using Tapatalk
Using today's build and the latest g-apps :
Everything seems much snappier. Only thing I noticed is a FC while playing "Words with Friends" (after making a move then backing out of the advertisement)
Sent from my NookColor using Tapatalk
That did it; it appears to have been either LCD Resolution or the JMRI throttle app. I uninstalled the former and disallowed the latter and I'm now running last night's opengl build. I'm much happier now.
Sent from my NookColor using xda premium
Yep, did that every time. Turns out to be a misbehaving superuser-allowed app.
I've had one spontaneous reboot, but all else is very smooth. A bit slower, perhaps, but smooth.
Sent from my CM9 NookColor using xda premium
I agree. I have used your recommended settings for a day and found it the most stable so far.
Thanks!
Thanks!
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
71As of 9/4 opengl is enabled on all builds (so no more double builds each night) and hardware UI acceleration is working. Thanks krylon360 for the work
In the same spirit as Samiam303 I've been building and hosting nightly builds of CM9 for the community to use. In particular I'm now building nightlies with OpenGL rendering turned on in addition to non-openGL builds (same as Samiam303). These builds are all straight sync with CM source with no additional mods. Builds are sync'd at 3am EST for non-openGL and 4am EST for openGL - they will be available to download approx 15 mins after their sync times.
So what does OpenGL rendering mean? It means we have some form of hardware acceleration for the UI and apps. It is not full hw accel and it is not hw video decoding. The couple of things you'll notice work is wallpaper scrolling in the launcher and chrome beta will mostly work to render webpages but will fc if you go into settings. Flash also somewhat works - I've found you definitely need to OC to get some flash videos to work, most still are not smooth.
The downside to it seems to vary user to user, some people report sluggish responses and some get lock ups, a few have no problems at all..
Either way, give them a try and report back. Please try to keep the thread on topic of these builds only, other mods can be flashed over, but that discussion should be in the respective thread. I'd also like to revisit keyodi's suggestion here (http://xdaforums.com/showthread.php?p=22277804#post22277804) - a few people reported good results with that change. Any more feedback?
Downloads
There's a few ways to get the builds:
1) Browse the hosted folder here: http://techerrata.com/browse/nightly_kangs/encore
2) Follow @CM_Encore on twitter for announcements of the builds as they hit the host (PLEASE NOTE: @CM_Encore IS A TWITTER BOT - don't bother tweeting at it)
3) *NEW* Use the Goo Manager app to receive notifications of new builds and download them directly on your nook. With Goo Manager you can also get incremental updates, see my post here: http://xdaforums.com/showthread.php?p=25441065#post25441065
Latest ICS gapps can be found here http://goo-inside.me/gapps or mirrored here http://techerrata.com/browse/gapps
Updates
For the latest updates/announcements follow me on twitter, or check back here.
5/9/12: Goo Manager now comes pre-installed to make updating as easy as possible
4/28/12: Incremental updates are available for the flash-a-holics: See http://xdaforums.com/showthread.php?p=25441065#post25441065
3/10/12: Due to some merges yesterday you may need to reflash gapps when going from a nightly prior to 3/9 to later than 3/9
Credit and Thanks
Thanks to fattire, dalingrin and the rest of the CM encore theme for making this possible. Thanks to fellow TeamWin members Kevank for providing the hosting and to s0up for the Goo app.26The 9/4 nightly includes all of krylon's changes, and opengl is now enabled by default so there will only be 1 build each night from now on (unless something changes again). In testing we haven't experienced any freezes or random reboots with the new code and opengl enabled, of course with wider testing we may discover something.19I've decided to pause the nightlies at this point. If most people are on 9/4 we can start to see if there's any specific issues affecting all users that might be able to be resolved with the goal being as stable a cm9 release as possible. There isn't much being merged into the cm9 tree upstream so we're not losing anything by building less frequency.
So go ahead and install 9/4, if I see something of significance merged upstream I'll kick off a new public build.17Nightlies will now feature HWA and full Hardware Decoding, as well as working Flash.
Known issues.
Netflix - Stupid Stupid App. - Giving the same error as we are getting in JB, so when we fix one, we will fix the other.
Fruit Ninja - Hangs at the loading screen. - Known issue across several devices.15
thanks eye.
This gives me a chance to hack in the PBHACK which will bring down the memory usage of SystemUI like I did in JB.
Gonna take some work since it didnt like some of the syntax usage when I attempted the 1st time.
Will try to get to this sometime this week. Have my Grandma coming to town on Sunday, so will be unavail this weekend/next week.
New posts
-
-
-
Features disabled on fastboot and bootloader. How do I enable them?- Latest: mayberandomparable
-
