I tried this Handler throwing messages at a specific rate solution. But I must admit I'm not terribly happy with it.
The problem is that if not enough processing power is available, the messages accumulate ! Making the application seem sluggish due to input Lag, since touch events seems to be placed after all these messages. However, when we use the keyboard, the key events seem to become readily available. I also tried to remove all pending messages with the same "what" value, when the handler callback runs, before setting a new message for refresh. I Think that this solution is not the definite solution for frame refresh at a pre-fixed framerate. 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. On Apr 17, 3:28 am, hackbod <[EMAIL PROTECTED]> wrote: > The point of the demo is to show how to do a continually updating > OpenGL display, such as used in a game. If that is not what you need, > you can use Handler to post a message at the rate you want to update > the display. > > On Apr 16, 5:50 pm, Macro <[EMAIL PROTECTED]> wrote: > > > In the demo of OpenGL, there launch a thread with an endless circle > > to draw the frame. > > But I believe the modus waste lots of system resource, there are any > > good modus? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
