I just added some debugging in and got a funny result. For this game, I only want MotionEvents that have the Action ACTION_DOWN. I filter and only put ACTION_DOWN events in the queue. When processing the queue, I sometimes get events that are not ACTION_DOWN! That should be impossible - unless the object was reused for a different event. That's the only reasonable explanation so I'm going to answer my own question and say that these events must be pooled and are not safe to queue up.
I'll write something to copy out the important stuff into my own managed pool so I'm not allocating either :) On Sep 11, 5:01 am, Robert Green <[email protected]> wrote: > Thanks for replying quickly but I'm asking about key and motion events > (touch), not sensor events. Also the problem I was having was that > for whatever reason, the UI thread was having problems acquiring the > lock on the synchronized block to push input into the game, even > though the game loop sleeps to allow for that thread to get gain the > lock. I didn't want to get into a discussion about that and wanted to > pipeline input to ensure that the game is playing nice with the UI > thread anyway. The pipeline works very well, with the exception of > the bit of weirdness I'm seeing, which is why I'm asking the question, > "Is it safe to queue MotionEvents and KeyEvents for deferred > processing?" > > On Sep 11, 4:42 am, XingChao Wang <[email protected]> wrote: > > > 2009/9/11 Robert Green <[email protected]> > > > > I decided to start pipelining input to increase responsiveness in my > > > games. Basically what I do is when the activity receives a Key or > > > Motion event, it sends it to a feed method in the game, which > > > encapsulates it with a time and whatever else I need and puts it in a > > > queue then immediately returns so the UI loop is never held up waiting > > > for long. The main loop later processes the queue, applying the > > > events in it at the appropriate times. > > > > This works great and makes the games snappy, although now I'm starting > > > to miss touch events intermittently. I realized that the events could > > > be recycled objects and that could make them not safe to queue. Is > > > this the case or is it safe to queue them for deferred processing like > > > I'm doing? > > > Kernel input event has low efficiency,you can change to input events > > to android sensor-manager,then Games app can get high response. > > > --wang xingchao > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
