Dianne, I want to thank you again for your advice - it actually helped. I process at most 10 touch movement events per second (good enough for the app) and sleep the UI thread after the moves - this did boost the second thread enough so that most of the app's time is spent in physics updates and drawing.
Thanks again, Stoyan On Sat, Jan 10, 2009 at 3:51 AM, Stoyan Damov <stoyan.da...@gmail.com> wrote: > I'll add that the time consumed by my view's onFingerMove is 2/3 of > the time to call (MotionEvent.getAction + .getX() + .getY()) - that > is, I'm pretty sure I'm not doing anything funny in my touch event's > handler. > > On Sat, Jan 10, 2009 at 3:14 AM, Stoyan Damov <stoyan.da...@gmail.com> wrote: >> On Sat, Jan 10, 2009 at 12:49 AM, Dianne Hackborn <hack...@android.com> >> wrote: >>> On Fri, Jan 9, 2009 at 1:22 PM, Stoyan Damov <stoyan.da...@gmail.com> wrote: >>>> >>>> I do "yield" to the main thread by calling mainActivity.runOnUiThread >>>> w/ a no-op (cached) runnable once per second but I guess that's not >>>> enough. I'll try increasing that to see if it will make a difference. >>>> I'd rather run the game @ 40 fps by losing ~15 fps because of yielding >>>> than losing ~30 fps because of touch event throttling. >>> >>> If I am reading that right, that's not a yield, that is just adding more CPU >>> using work on the main thread. :) What you want to do is force the main >>> thread to actually stop running for a bit after processing an event, so that >>> it isn't using the CPU and your other thread can run and the window manager >>> doesn't immediately turn around and give you another event with more work to >>> do. >> >> Now you got me confused :) but let me 1st explain that by yielding I >> meant that the game thread yielded to the UI one. >> >> My confusion (now) is that I thought (after your post) that the main >> UI thread was not given enough time to process touch events and the OS >> was doing something (more work) because of that and was leaving my app >> with less time to work. You're now saying it's the opposite, but that >> can't be the problem because before I added the yields, the game >> thread was running at full speed and the UI was so unresponsive (e.g. >> clicking the Menu button resulted in ANR) that I had to do something >> about it and start yielding to the UI thread from the game one >> occasionally. >> >> However, I realize that you're not really saying to not let the UI >> thread work but to make it unresponsive for a bit every now and then >> (after an event is processed) so that the game thread works more and >> less context switches (made by Android's thread scheduling mechanism, >> not by me marshalling calls) occur. Is that what you're saying? >> >> Now just before I was about to post this, I profiled the game and let >> me share some *very* interesting facts about the touch handling. >> >> I ran the game, touched (which triggers the profile start process), >> and immediately removed my finger from the screen and let the >> profiling finish. >> What I saw in Traceview is that 64.7% of the game's time went in >> drawing (which is great!), 33.8% in the game's update, and >> android.os.Handler.dispatchMessage(Message) takes the funny 0.2% - I'm >> mentioning dispatchMessage here because you'll see a DRASTIC change in >> a second. >> >> I then ran the game, touched the screen and started moving my finger >> without releasing it until the profiling stopped. >> What I saw in Traceview is that 49.1% went in the game's update code, >> only 9% in the draw code and now for the winner - >> Handler.dispatchMessage took 24.7% of the time :O :O :O >> This only makes me think that my assumption that the layers below the >> app are doing something more than expected :( >> I'm yet to find out why would the update vs draw time is 49% to 9% >> (maybe locking the canvas and event handling on the UI thread are >> somewhat related???), but having an overhead of 25% just because I'm >> touching the screen is too much for me. >> >> Cheers >> >>> >>>> >>>> I'd rather "control" the priority myself :) >>> >>> How are you going to control the priority yourself? >> >> Now that you understand what I meant by yielding (that is, not to the >> OS but from the game to the main/UI thread) I guess that question is >> moot. >> >> Cheers >> >>> >>> -- >>> Dianne Hackborn >>> Android framework engineer >>> hack...@android.com >>> >>> Note: please don't send private questions to me, as I don't have time to >>> provide private support. All such questions should be posted on public >>> forums, where I and others can see and answer them. >>> >>> >>> >>> >>> >> > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
