[Android] Cache additional MotionEvent bits in MotionEventAndroid

[Android] Cache additional MotionEvent bits in MotionEventAndroid

Closer inspection of MotionEventAndroid usage revealed that several uncached
properties were being accessed on average 2x or more times per event, incurring
significant JNI costs.  Address this by caching these properties (pointer id,
touch size and touch position) for the most common touch scenarios (scroll and
pinch).  This reduces the time spent processing touch events in the browser by
~20% (.1ms) during scrolling, and ~40% (.2ms) during pinching on a typical
Android device.

BUG=341613
NOTRY=true

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=255789

[jdduke (slow), 2014-03-07 01:09:24]

aelias@: PTAL.  I always suspected we might not be caching all the necessary
bits, and sure enough...

[aelias_OOO_until_Jul13, 2014-03-07 01:18:16]

lgtm

Hmm, this raises the question of if we could do better with a "push a big struct
across JNI boundary" model.  It would probably require improving the tooling to
do this cleanly though...

[jdduke (slow), 2014-03-07 03:23:26]

On 2014/03/07 01:18:16, aelias wrote:
> lgtm
> 
> Hmm, this raises the question of if we could do better with a "push a big
struct
> across JNI boundary" model.  It would probably require improving the tooling
to
> do this cleanly though...

So, I actually played with a version that pushed a bunch of cached values from
Java in a single giant method call.  I abandoned it without doing a ton of
testing (all of the Java MotionEvent getters still have to travel *back* to C++
for the native-backed MotionEvent that we sadly don't have direct access to =/).
 Maybe I'll resurrect that and actually get a solid timing result, and/or
explore using a struct as you say.

[jdduke (slow), 2014-03-07 20:30:33]

I uploaded a version that provides all cached values along with the touch event
injection.  I expected it to have a bigger impact on overall touch handling
time, but it was very minor (~10us or less).  That may be because we're not
saving quite as much because the MotionEvent queries still have to go down to
native to get the underlying data.  I'm not sure if the increased
verbosity/complexity is worth it here, wdyt?

[aelias_OOO_until_Jul13, 2014-03-07 20:35:20]

It's more verbose but it's not more complex: in some ways it's simpler since all
the data is treated the same way.  I'm fine with this, lgtm.

[jdduke (slow), 2014-03-07 21:36:15]

The CQ bit was checked by jdduke@chromium.org

[commit-bot: I haz the power, 2014-03-07 21:37:19]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jdduke@chromium.org/189693002/60001

[commit-bot: I haz the power, 2014-03-08 11:00:47]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jdduke@chromium.org/189693002/60001

[commit-bot: I haz the power, 2014-03-08 12:47:00]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-08 12:47:01]

Retried try job too often on win for step(s) compile
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win&number...

[jdduke (slow), 2014-03-08 13:46:21]

The CQ bit was checked by jdduke@chromium.org

[commit-bot: I haz the power, 2014-03-08 13:46:59]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jdduke@chromium.org/189693002/60001

[commit-bot: I haz the power, 2014-03-08 14:43:11]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-08 14:43:11]

Retried try job too often on mac_rel for step(s) telemetry_perf_unittests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=mac_rel&nu...

[jdduke (slow), 2014-03-08 15:17:59]

The CQ bit was checked by jdduke@chromium.org

[commit-bot: I haz the power, 2014-03-08 15:18:11]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jdduke@chromium.org/189693002/60001

[commit-bot: I haz the power, 2014-03-08 15:56:13]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-08 15:56:14]

Retried try job too often on mac_rel for step(s) telemetry_perf_unittests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=mac_rel&nu...

[jdduke (slow), 2014-03-08 16:24:12]

The CQ bit was checked by jdduke@chromium.org

[commit-bot: I haz the power, 2014-03-08 16:24:24]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jdduke@chromium.org/189693002/60001

[commit-bot: I haz the power, 2014-03-08 18:08:53]

Change committed as 255789