Thanks for your thoughts. I've started handing off my input events using a concurrent queue, and that seems to handle the blocking issue.
Now I've started testing out my saveState code, which also has a synch block, and it's having the same issue. Should I send a "savestate" message down the pipeline and let the thread itself handle the save? Or do the yield thing? BTW, I've checked out your blog before, nice, informative stuff! On May 8, 1:09 am, Robert Green <rbgrn....@gmail.com> wrote: > Josh, > > I used to have that exact same problem. There are a few things you > can do. One is try having your logic thread call Thread.yield() which > hopefully will let the UI thread get the synchronized block and inject > the touch event. The other is to separate the locking so that you > only block the UI thread when you're processing touch events, not > while your thread is running (which is always and is why you're having > this problem). > > I set up a queue for input objects and the only time the queue > insertion is blocked is when my logic thread is actually processing > the events, which is for only a fraction of the total update time. > Check out my code here > -http://www.rbgrn.net/content/342-using-input-pipelines-your-android-game > > Once you implement that (if you do), you should have less problems. > > On May 7, 1:05 pm, Josh <josh.olek...@gmail.com> wrote: > > > > > > > I'm trying to use the structure laid out in LunarLander to create a > > simple game in which the user can drag some bitmaps around on the > > screen (the actual game is more complex, but that's not important). I > > ripped out the irrelevant parts of LanderLander, and set up my own > > bitmap drawing, something like > > > In BoardThread (an inner class of BoardView): > > run() > > { > > while(mRun) > > { > > canvas = lockSurfaceHolder... > > syncronized(mSurfaceHolder) > > { > > /* drawStuff using member position fields > > in BoardView */ > > } > > unlockSurfaceHolder > > } > > > } > > > My drawStuff simply walks through some arrays and throws bitmaps onto > > the canvas. All that works fine. Then I wanted to start handling touch > > events so that when the user presses a bitmap, it is selected, when > > the user unpresses a bitmap, it is deselected, and if a bitmap is > > selected during a touch move event, the bitmap is dragged. I did this > > stuff by listening for touch events in the BoardView's parent, > > BoardActivity, and passing them down into the BoardView. Something > > like > > > In BoardView > > handleTouchEvent(MotionEvent e) > > { > > synchronized(mSurfaceHolder) > > { > > /* Modify shared member fields in BoardView > > so BoardThread can render the bitmaps */ > > } > > > } > > > This ALSO works fine. I can drag my tiles around the screen no > > problem. > > > However, every once in a while, when the app first starts up and I > > trigger my first touch event, the handleTouchEvent stops executing at > > the synchronized line (as viewed in DDMS). The drawing loop is active > > during this time (I can tell because a timer changes onscreen), and it > > usually takes several seconds or more before a bunch of touch events > > come through the pipeline and everything is fine again. > > > This doesn't seem like deadlock to me, since the draw loop is > > constantly going in and out of its syncronized block. Shouldn't this > > allow the event handling thread to grab a lock on mSurfaceHolder? > > What's going on here? Anyone have suggestions for improving how I've > > structured this? > > > Some other info. This "hang" only ever occurs on first touch event > > after activity start. This includes on orientation change after > > restoreState has been called. Also, I can remove EVERYTHING within the > > syncronized block in the event handler, and it will still get hung up > > at the syncronized call. > > > Thanks! > > > -- > > You received this message because you are subscribed to the Google > > Groups "Android Developers" group. > > To post to this group, send email to android-developers@googlegroups.com > > To unsubscribe from this group, send email to > > android-developers+unsubscr...@googlegroups.com > > For more options, visit this group > > athttp://groups.google.com/group/android-developers?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com > For more options, visit this group > athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
