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 <[email protected]> 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 [email protected] > To unsubscribe from this group, send email to > [email protected] > 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 [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
