Yes you should definitely put a small Yield or sleep in the drawing thread, this will allow the UI thread to process events. Also make sure to only synchronize exactly when you need to. For example, dont synchronize while checking which touch action it is, etc. Instead synchronize only right before you change the global shared value.
-niko On May 9, 9:41 am, Josh <josh.olek...@gmail.com> wrote: > 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 > 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
