[Q] - Windows Animation Speed? - HTC EVO 3D

Does anyone know how to speed up the window animation speed in the ROM without using Spare Parts? How to cook it into the ROM?

---

scrosler said:
Does anyone know how to speed up the window animation speed in the ROM without using Spare Parts? How to cook it into the ROM?
Click to expand...
Click to collapse
Great question. The quickest method which came to mind was to use look at the Spare Parst app source code and find how its controlling the window animation speed.
I purely speculate, there are two ways of controling window animation speed.
1) modifying a setting in a preference file in /data.
2) setting something in the android system via java.
Unfortunately the master source would be android.git.kernel.org (specifically http://android.git.kernel.org/?p=platform/development.git;a=tree;f=apps/SpareParts;hb=HEAD ) but the server is still offline. I'm not able to quickly find the Spare Parts app source code through google searching. If somebody does have a link to the online source code for Spare Parts, I'd be interested in taking a look and seeing how it works!
The only semi helpful link I could find is an older XDA thread: http://forum.xda-developers.com/archive/index.php/t-708774.html . Unfortunatley it appears he has taken his github files offline so I wasn't able to find the Spare Parts java source code.
Sorry for not having a specific answer but hopefully the ideas provide a lil more guidance!

---

joeykrim said:
Great question. The quickest method which came to mind was to use look at the Spare Parst app source code and find how its controlling the window animation speed.
I purely speculate, there are two ways of controling window animation speed.
1)modifying a setting in a preference file in /data.
2) setting something in the android system via java.
Unfortunately the master source would be android.git.kernel.org (specifically http://android.git.kernel.org/?p=platform/development.git;a=tree;f=apps/SpareParts;hb=HEAD )but the server is still offline. I'm not able to quickly find the Spare Parts app source code through google searching. If somebody does have a link to the online source code for Spare Parts, I'd be interested in taking a look and seeing how it works!
The only semi helpful link I could find is an older XDA thread: http://forum.xda-developers.com/archive/index.php/t-708774.html . Unfortunatley it appears he has taken his github files offline so I wasn't able to find the Spare Parts java source code.
Sorry for not having a specific answer but hopefully the ideas provide a lil more guidance!
Click to expand...
Click to collapse
Thanks for looking into this. I will post back if I find anything but as of now I havent found squat.

---

scrosler said:
Does anyone know how to speed up the window animation speed in the ROM without using Spare Parts? How to cook it into the ROM?
Click to expand...
Click to collapse
Gotcha.
Add (or edit that number..higher=faster) this line in the build.prop:
windowsmgr.max_events_per_sec=100
(MAKE SURE there's still a blank line at the end of all your build.prop tweaks, or it won't "take".)
<<bringing it since 2010>>

---

mazook98 said:
Gotcha.
Add (or edit that number..higher=faster) this line in the build.prop:
windowsmgr.max_events_per_sec=100
(MAKE SURE there's still a blank line at the end of all your build.prop tweaks, or it won't "take".)
<<bringing it since 2010>>
Click to expand...
Click to collapse
Thanks man!
Is there a max?
Gonna try 300 now...

---

scrosler said:
Thanks man!
Is there a max?
Click to expand...
Click to collapse
Lol... It gets wonky over 110 in most roms.. In fact, 100 is at the high range. Most chef's that add this usually come in about 90, but I've never had issues with 100.
LMK how it works for you.
<<bringing it since 2010>>

---

mazook98 said:
Lol... It gets wonky over 110 in most roms.. In fact, 100 is at the high range. Most chef's that add this usually come in about 90, but I've never had issues with 100.
LMK how it works for you.
<<bringing it since 2010>>
Click to expand...
Click to collapse
Yea, I was rocking 100... But... When I changed it up to 200 nothing changed. Gonna drop down very low to test theory.
Something that SpareParts+ is doing is making it haul ass. Much faster than what it is now.

---

Changed to 50 and see no difference. Hmmm.....

---

Are you clearing Dalvik in between changes? (If, that is, you're in one of your awesome deodexed roms?)
I think all your apps are opted in relation to build.prop guidelines, so that would be needed.
<<bringing it since 2010>>

---

mazook98 said:
Add (or edit that number..higher=faster) this line in the build.prop:
windowsmgr.max_events_per_sec=100
(MAKE SURE there's still a blank line at the end of all your build.prop tweaks, or it won't "take".)
Click to expand...
Click to collapse
scrosler said:
Changed to 50 and see no difference. Hmmm.....
Click to expand...
Click to collapse
wasn't much information provided on what this build.prop line edit actually does or how android implements the number values. so researched this setting - windowsmgr.max_events_per_sec.
first found an older thread on XDA about it. they claim you can adjust the value after boot but it won't change anything until after a reboot. i.e. setprop *should* work on changing the value, but won't have any impact. seems have to edit/save actual build.prop and restart.
also they state 55 is the default value and the android framework doesnt recognize values under 35.
they also say: "That value does not affect the framerate, but how many touch events are reported to the apps; this saves some cpu if the user keeps touching the screen." all this information is taken from this thread - http://forum.xda-developers.com/showthread.php?t=813309
read on another forum post, "To enable better scrolling speed through lists, I changed windowsmgr. max_events_per_sec=55 to windowsmgr.max_events_per_sec=60. Scrolling through the app drawer and contacts and any lists really is now smoother. " - http://androidforums.com/droid-x-all-things-root/164447-mod-lots-build-prop-edits.html
not able to find anything from google/android developers to reference as an "official" source .. maybe a grep through aosp code could reveal where android reads and implements this build.prop setting change.
hopefully some of that information helps sheds a bit more light on this "tweak", i.e. default value, range, areas it will impact, etc.

---

After reading your post I would believe this is not the golden egg I am looking for. Im going to decompile SpartParts+ and see what, if anything I can find by poking around.

---

mazook98 said:
Are you clearing Dalvik in between changes? (If, that is, you're in one of your awesome deodexed roms?)
I think all your apps are opted in relation to build.prop guidelines, so that would be needed.
<<bringing it since 2010>>
Click to expand...
Click to collapse
No, I didnt clear cache but I can try... Cant hurt, right? I just dont think this the correct mod... But what the heck/.... Lets see if clearing any thnig helps.

---

Nope, nothing.

---

scrosler said:
After reading your post I would believe this is not the golden egg I am looking for. Im going to decompile SpartParts+ and see what, if anything I can find by poking around.
Click to expand...
Click to collapse
first approach which comes to mind: i'd prob grep through there looking for any strings regarding window animation speed. i forget what it is called in the real app, but that is probably a great starting point. then start back tracing the code .. i don't deal much with smali but i'm sure you'll be able to trace it down.
keep us updated!

---

scrosler said:
Nope, nothing.
Click to expand...
Click to collapse
Sorry to sidetrack you Scott!
I "thought" I knew what I was talking about...
Good luck in the effort, bro.
(and I'll also stop editing that line into every single build.prop I see, lol.)
Thanks for the work.
<<bringing it since 2010>>

---

joeykrim said:
first approach which comes to mind: i'd prob grep through there looking for any strings regarding window animation speed. i forget what it is called in the real app, but that is probably a great starting point. then start back tracing the code .. i don't deal much with smali but i'm sure you'll be able to trace it down.
keep us updated!
Click to expand...
Click to collapse
That was my plan of attack.. somewhat.. Lets see how complicated the code is in this... iM hoping its using an echo command or something similar... Because the speed change sticks after a reboot so wouldn't that indicate its writing to a file?
mazook98 said:
Sorry to sidetrack you Scott!
I "thought" I knew what I was talking about...
Good luck in the effort, bro.
(and I'll also stop editing that line into every single build.prop I see, lol.)
Thanks for the work.
<<bringing it since 2010>>
Click to expand...
Click to collapse
Its all good man. Atleast you tried.

---

scrosler said:
That was my plan of attack.. somewhat.. Lets see how complicated the code is in this... iM hoping its using an echo command or something similar... Because the speed change sticks after a reboot so wouldn't that indicate its writing to a file?
Click to expand...
Click to collapse
yea, i would agree. wish i had taken a look at the spare parts source code when it was posted on the android aosp site!
i doubt its using echo to send a value to a sysfs file generated by the kernel. my guess would be to a data settings file on the /data partition. at least thats what i'd hope as that would be easy to duplicate!
if you want to post up the smali files, i can try and take a look through. yay for java being so easy to reverse!

---

joeykrim said:
yea, i would agree. wish i had taken a look at the spare parts source code when it was posted on the android aosp site!
i doubt its using echo to send a value to a sysfs file generated by the kernel. my guess would be to a data settings file on the /data partition. at least thats what i'd hope as that would be easy to duplicate!
if you want to post up the smali files, i can try and take a look through. yay for java being so easy to reverse!
Click to expand...
Click to collapse
Related dumb (awesome) geek joke:
Q: Why do all Java developers wear glasses?
.
.
.
A: Because they can't C#.
(ba dump bump).
<<I first learned about binary from Pac Man>>

---

Ill drop you a pm for this when I get home. It is NOT the build prop edit posted earlier. That has ZERO to do with animation speed.

---

SteelH said:
Ill drop you a pm for this when I get home. It is NOT the build prop edit posted earlier. That has ZERO to do with animation speed.
Click to expand...
Click to collapse
Thanks man! As always your tutorials make my ROM! They are unbeatable!