On Friday, April 8, 2011 4:51:23 PM UTC+9:30, Dianne Hackborn wrote: > > I wouldn't suggest having a handler sitting there trying to post messages > to itself as fast as possible. You are just writing code that sits there > consuming every bit of CPU it can get for no useful reason. Either use > postMessageDelayed/AtTime() to actually have controlled timing, or just do > invalidate() each time you draw to tie to the frame rate.
I wouldnt have thought it would work like a busy method if its adding itself to something like an event queue or whatever, but I'll take your word on it. Having said that Im pretty sure that your suggestion to invalidate() at the end of onDraw() would turn out to be busy too. I have changed the line to this.postDelayed(this, 10); with no change in fps according to my code so that appears to be the best thing to do for the cpu anyway. > That said, if you are getting glitches of significantly less than 60fps > than you simply have performance issues. Look at the log to see if you are > GCing a lot (hint: you absolutely do not want to be creating temporary > objects in your drawing path), and use the profiling to see what is taking a > long time in your code. > I held my device up to my monitor so I could watch logcat and the animation at the same time, and it seems like it is the GC. It busts a move every 5-10 seconds and results in a split second jolt in the animation. I've poured through the code and pulled out many unnessecary temporary objects, but it will still need further work - thanks for that tip! -Numeron -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
