Touch Screen events Throttling in WIndowManager

86 views
Skip to first unread message

DineshG

unread,
Oct 7, 2009, 12:05:10 AM10/7/09
to android-platform

There is a limit of 35 events per second introduced in WindowManager
for the Touch Screen events in Donut and seems
like work is still going on to finalize the magic number which as of
now is 35 or make it app specific.

My limited analysis actually shows significant improvement in the cpu
utilization by imposing this limit but
I would like to understand other implications of this in general and
on screen update FPS in particular.

Once finalized , is it safe to back port this to cupcake ? thanks

Dianne Hackborn

unread,
Oct 7, 2009, 12:12:17 AM10/7/09
to android-...@googlegroups.com
I am pretty sure the final Donut source is in the tree, and that is what it is going to be.  And yes, this was done to reduce CPU usage for applications that don't do much work in their main thread.
--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

Jean-Baptiste Queru

unread,
Oct 7, 2009, 8:30:04 AM10/7/09
to android-...@googlegroups.com
I confirm that one of the variants of the final donut tree is
currently released as android-1.6_r1 (it precisely matches the system
image in the SDK).

JBQ
--
Jean-Baptiste M. "JBQ" Queru
Software Engineer, Android Open-Source Project, Google.

Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further
warning.

DineshG

unread,
Oct 7, 2009, 3:56:18 PM10/7/09
to android-platform

What is the basis for finalizing the magic number "35" ?
Does this limit not throttle the FPS for the screen updates as well ?
How about porting this back on cupcake ?


On Oct 7, 5:30 am, Jean-Baptiste Queru <j...@android.com> wrote:
> I confirm that one of the variants of the final donut tree is
> currently released as android-1.6_r1 (it precisely matches the system
> image in the SDK).
>
> JBQ
>
>
>
> On Tue, Oct 6, 2009 at 9:12 PM, Dianne Hackborn <hack...@android.com> wrote:
> > I am pretty sure the final Donut source is in the tree, and that is what it
> > is going to be. And yes, this was done to reduce CPU usage for applications
> > that don't do much work in their main thread.
>
> > On Tue, Oct 6, 2009 at 9:05 PM, DineshG <dinesh.n...@gmail.com> wrote:
>
> >> There is a limit of 35 events per second introduced in WindowManager
> >> for the Touch Screen events in Donut and seems
> >> like work is still going on to finalize the magic number which as of
> >> now is 35 or make it app specific.
>
> >> My limited analysis actually shows significant improvement in the cpu
> >> utilization by imposing this limit but
> >> I would like to understand other implications of this in general and
> >> on screen update FPS in particular.
>
> >> Once finalized , is it safe to back port this to cupcake ? thanks
>
> > --
> > Dianne Hackborn
> > Android framework engineer
> > hack...@android.com

Romain Guy

unread,
Oct 7, 2009, 4:00:01 PM10/7/09
to android-...@googlegroups.com
This does not throttle the screen drawing, only the number of touch
events per second.
--
Romain Guy
Android framework engineer
roma...@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

Dianne Hackborn

unread,
Oct 7, 2009, 5:59:57 PM10/7/09
to android-...@googlegroups.com
And MotionEvent contains the batch of data since the last event, so you are not losing any data.
hac...@android.com

DineshG

unread,
Oct 7, 2009, 6:55:43 PM10/7/09
to android-platform
Hmmmm ,

For the addBatch() function documentation ,
"Add a new movement to the batch of movements in this event. The
event's current location, position and size is updated to the new
values. In the future, the current values in the event will be added
to a list of historic values."
the last line confused me and I assumed that as of now you are just
dropping the previous events and over-writing the current event with
the latest one.

But still curious to understand why "35" ?

On Oct 7, 2:59 pm, Dianne Hackborn <hack...@android.com> wrote:
> And MotionEvent contains the batch of data since the last event, so you are
> not losing any data.
>
>
>
> On Wed, Oct 7, 2009 at 1:00 PM, Romain Guy <romain...@google.com> wrote:
>
> > This does not throttle the screen drawing, only the number of touch
> > events per second.
>
> > romain...@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

Dianne Hackborn

unread,
Oct 7, 2009, 7:18:17 PM10/7/09
to android-...@googlegroups.com
No, the MotionEvent has always contained all of the intermediate points since the last one, and addBatch() has always taken care of this.
hac...@android.com

Hexage

unread,
Oct 8, 2009, 4:27:56 AM10/8/09
to android-platform
I've tested our games on 1.6 and this really helps. Together with
changes to the scheduling of background threads it makes 1.6 much
better for games.

Thank you guys, keep up the good work!

David
Reply all
Reply to author
Forward
0 new messages