On Sat, Jan 10, 2009 at 12:49 AM, Dianne Hackborn <hac...@android.com
> On Fri, Jan 9, 2009 at 1:22 PM, Stoyan Damov <stoyan...@gmail.com
>> 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
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
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
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
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.
>> 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