Hmm, This sounds very similar to my situation. My game update loop takes the lock just once, updates the game state (a relatively fast operation), releases the lock and then performs rendering to a surface (a relatively slow operation). The game currently executes the loop in about 50ms. The amount of time that the lock is held by this update thread is significantly less than 1ms per loop.
Within the touch handler, the event thread contends for this lock on each down touch event (ie. very infrequently). And yet (iirc from the last time I investigated) it appeared that the event thread was indeed blocking on the acquisition of my game state lock - long enough to trigger an ANR. At the same time I can see the game continuing to run smoothly, so I know the the lock must be being released many times a second! It has all the hallmarks of an issue in the way monitors are being handled by the Java threads (I'm pretty sure the JLS requires fairness). BUT any attempt to produce a test case that is significantly smaller and that triggers the issue frequently enough has failed. So the jury is out, I could well have a bug somewhere. I refuse to 'fix' this by removing the synchronization. I don't see why you should need to. Note that the apparently easy fix of removing the synchronization block will almost certainly introduce a bug into the code, even if the chances of it being triggered are probably extremely low. Tom. 2009/2/8 Zombies and Robots <[email protected]> > > I figured out what was causing my particular problem. Both the method > that draws the SurfaceView and the method that handles the touch > events were synchronized with the same object. I'm guessing the > delays were caused because the touch event handler method couldn't > access this object while the drawing method was running... which was > just about all the time. To resolve the problem, all I had to do was > remove the synchronization from the touch event handler method and > modify my drawing method so that it accessed the camera's location > only once (which I would have done in the first place had I been > writing efficient code). > > I'm feeling pretty dumb for missing that... but thank you nonetheless > for your helpful responses! They definitely got me thinking toward > the solution. > > On Feb 6, 7:58 pm, Al <[email protected]> wrote: > > Hi, have you checked the trace file that is written when an anr > > occurs? It shoud be in /data/anr with the filename traces.txt. This > > will show exactly what was running and at what line of code when the > > anr popped up and should help locate the problem code. > > > > On Feb 6, 7:03 pm, Zombies and Robots <[email protected]> wrote: > > > > > Hello. > > > > > I am working on a game that displays its graphics through a modified > > > SurfaceView. The game scrolls around a map based on the location of > > > the main character. That all works fine. > > > > > I am trying to add a feature to the game that allows you to touch the > > > screen and drag the camera around to see other parts of the map. This > > > is where I am running into trouble. The game's SurfaceView overrides > > > 'public boolean onTouchEvent(MotionEvent event)' to call another > > > method in the game's thread which handles the events. Sometimes, this > > > works fine (although the frame rate drops significantly while the > > > screen is touched). Other times, there will be a delay of several > > > seconds before the game responds to a touch event, during which time > > > the game continues, but the user loses all control. During these > > > delays, a message sometimes appears stating that my activity is not > > > responding, and giving the options to 'Force close' or 'Wait'. If the > > > user selects 'Wait', the game almost always resumes right away, but > > > these delays are obviously not acceptable. > > > > > The delays occur only the first time the screen is touched after the > > > game is started. Once the game has resumed after a delay, the touch > > > events work just fine again. > > > > > I have experimented with having the game thread sleep for short > > > periods at various points throughout the game. Although this does > > > seem to have a small effect on the problem, the delays still happen. > > > Has anyone else run into this? What am I doing wrong? > > > > > Thank you very much for any suggestions you can provide. > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
