On Apr 17, 10:51 am, Rui Martins <[EMAIL PROTECTED]> wrote: > The problem is that if not enough processing power is available, the > messages accumulate !
Just send a new message as part of processing the previous one. > I Think that this solution is not the definite solution for frame > refresh at a pre-fixed framerate. I can assure you it works fine. > In some cases, although heavier for the mobile cpu and battery, it > seems to work better, to just have an invalidate has the last > instruction of the onDraw(....) method. > It refreshes as fast as possible, without messing with message > handling resources, but drains battery and CPU to the MAX. Doing this is exactly the same as the open gl example with a thread updating the screen as fast as possible. Note that, as another poster said, the system doesn't allow you to update a surface faster than the refresh rate of the screen, soon in either case you will only use as much CPU as you need to keep the screen updated at its full rate... which is usually the entire goal of code like this. Oh and internally when you call invalidate(), guess what... it is posting a message to the message queue. :) --~--~---------~--~----~------------~-------~--~----~ 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] Announcing the new M5 SDK! http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
