I'm assuming you are referring to Handler.removeMessages? Unfortunately, from my understanding that will simply wipe the messages out of the queue. Need something that will let me process the messages currently in the queue so I can go back to rendering the next frame.
On Jul 14, 3:07 pm, Ward Willats <[email protected]> wrote: > Messages themselves have a method to remove all messages with id X > from the queue, I seem to recall. This may or may not be inconvenient > for you though. > > -- Ward > > At 2:30 PM -0700 7/14/09, Micah wrote: > > > > >I have a thread that does all my rendering code for a game (including > >animations). I want to be able to communicate with that thread via > >Messages instead of locking / synchronization. This means that I need > >to both support a message queue and *also* support my own rendering > >loop. Normally I would just clear the message queue every frame of > >rendering so worst case scenario the messages sit on the queue for one > >frame before getting cleared out. This also gives a bit of priority > >to messages in that if the queue backs up the rendering will take a > >back seat until it empties out. > > >Everything was going fine until I realized that Looper doesn't have a > >"Clear the Queue" function! I looked at the source code for > >Looper.loop() and it appears that the code necessary to manually > >traverse the MessageQueue is protected, so I can't even write the > >ClearQueue function myself. > > >Does anyone here have any feedback on how I can have a thread that > >keeps the MessageQueue clear at the same time as allowing me to peg > >the CPU rendering as many frames per second as I can? > > >My current thought is to insert a message into the MessageQueue along > >the lines of "RenderOneFrame". When this message is popped off the > >queue I would render one game frame. Before returning from my > >rendering code though I would push another copy of the RenderOneFrame > >message back onto the queue. This means any messages added to the > >queue while I was busy rendering the frame would get processed before > >the RenderOneFrame mesage and once the queue was "clear" (ie: > >RenderOneFrame message was back on top) I would repeat the process. > > >I suspect that this will work, though I am open to suggestions for > >either a clear or faster method (I'm more interested in clean at this > >point, but at optimization time I'll be interested in faster if I > >bottleneck on this code). --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
