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 -~----------~----~----~----~------~----~------~--~---
