I've finally nailed a semi-reproducible test case for this and have raised an issue:
http://code.google.com/p/android/issues/detail?id=1956 This is a nasty bug - I think it's a showstopper for me in this application: I have too much state associated with touch events to avoid synchronization and the only workarounds I can think of involve lots of object creation. Tom. 2009/2/8 Tom Gibara <m...@tomgibara.com> > 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 <caecus...@gmail.com> > > >> 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 <alcapw...@googlemail.com> 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 <caecus...@gmail.com> 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 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 -~----------~----~----~----~------~----~------~--~---
