Thanks, glad to hear it helped. Sorry I was slow responding to your last detailed message.
Fwiw, you should generally avoid trying to directly control scheduling. Let the kernel schedule the threads as needed; the only issue you had here was that your main thread was using as much CPU as it could get, since it was continually processing touch events, so the kernel would schedule 50/50 between that and the game thread. Simply reducing the work being done by the main thread (by our little hacky sleep solution) is probably the best way to fix things. On Sat, Jan 10, 2009 at 1:19 PM, Stoyan Damov <stoyan.da...@gmail.com>wrote: > > 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. > >>> > >>> > >>> >>> > >>> > >> > > > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
