Just an additional clarification, this behavior occurs when the 2 touches are on different elements.  In the touchlist-objects demo above, if you press and hold the blue button with the first finger, and then press and hold the same blue button but with a 2nd finger, both sets of circles are firing touchmove events with normal frequency and the animations are smooth.  However, if one finger is on the button, and another finger is somewhere other than the button (on a different element) then the stuttering occurs when trying to move the 2nd touch.

This applies to my repo example (the first example in this bug report) because the first finger is pressing and holding the camera fly forward button (an element), and the 2nd finger is not on that button (a different element) but trying to move the 2nd finger around results in the stuttering touchmove behavior.  

Thank you!

There are all kinds of devtools warnings on the page. Have you tried applying touch-action: none to the body?

I know we had some slowness due to the violation API (see issue 784027)

Ok I'll try to add the touch-action:none to the body and I'll report back any findings. Issue 784027 could possibly be related, but this seems to happen to me when I have 1 finger down already on an element, and then wish to place a 2nd finger touch down and swipe (touchmove) with that 2nd one. When there is only 1 touch, or both first and second touches are started on the same element, it works perfectly.
Thanks

Thank you for providing more feedback. Adding requester "dtapuska@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Hi again - yes applying the 'touch-action: none' to the document body takes away the choppiness and stuttering.  Was this due to default pinch and zoom messages being sent from the document body when I had more than 1 touch?  If so, thank you for the recommendation!

Just a side note, even though the choppiness is gone, when swiping with the 2nd finger it doesn't update quite as fast as when I'm dragging around with just 1 finger only.  It's a small difference, but it's the kind where you can tell that 1 finger touchmove is 60fps and 2 fingers touchmove 2nd finger is 30fps - still acceptable but not the same silky movement.  Is there another issue already filed about this behavior?

Thanks again

Here's my updated demos:
https://erichlof.github.io/THREE.js-PathTracing-Renderer/Geometry_Showcase.html

and this one will hopefully have less warnings:
https://erichlof.github.io/THREE.js-PathTracing-Renderer/CornellBox_DirectLighting.html

Thanks!

Can you provide an input latency trace? Then we can see what is taking time
on your device.

Ok I'll be glad to, it's just I have never recorded info like that before. Could you please post a link to instructions on how to record traces on Android?  After I understand how to do it I will get it to you soon. It might take a day or two. Thanks :-)

Hi, nevermind, I figured it out with the extra Android to Windows documentation and StackOverflow post(that was very helpful btw!).

Here is the recording from my Samsung Galaxy S7 Edge
I briefly swipe with just 1 touch.  Then in the last half, I first hold down the little up arrow button with the 1st finger, while attempting to press with a 2nd finger and swipe with that 2nd finger, all while holding the 1st finger down on a button element.

Thank you

Deleted: Profile-20180121T025652.json 8.4 MB

Profile-20180121T025652.json 8.4 MB View Download

The trace you provided doesn't show the input events that I was after.

Consult https://www.chromium.org/developers/how-tos/trace-event-profiling-tool/recording-tracing-runs#TOC-Capture-a-trace-from-Chrome-on-Android-with-DevTools-

It does show that you are doing a lot of GPU work. Each frame is taking about 46ms of GPU work; I expect that the vsync messages are delayed due to all the raster work which then slows down the rate at which input is delivered. Not sure why you'd see it two fingers and not just one. Perhaps you have more advanced workload with 2 fingers?

Hello, sorry about that - still learning about dev tools ;-)
Thanks for the link!  Here are the traces you requested:

1st trace is normal 1 finger swiping around the screen.
2nd trace is 2-finger where the first finger is holding down a button element, while the 2nd finger is swiping around the screen as in the first trace.

Thank you for taking a look!

Deleted: trace_InputLatency-Trace-1Finger.json 7.9 MB

trace_InputLatency-Trace-1Finger.json 7.9 MB View Download

Deleted: trace_InputLatency-Trace-2Fingers.json 9.3 MB

trace_InputLatency-Trace-2Fingers.json 9.3 MB View Download

Thank you for providing more feedback. Adding requester "dtapuska@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The BeginFrame times are pretty slow. Some are like 60ms, and are all over the board. The lower threshold is like 11ms.

Over to the graphics team to have a look.

Ok thanks for forwarding it to the graphics team.  To answer your earlier suspicions, I don't really do any extra GPU work on my app's end when 2 fingers are down instead of 1 (at least I don't think I am).  It's basically a screen size quad with a fragment shader that casts a ray from every pixel.  When a finger is down moving around, that triggers an event listener like touchmove or touchstart or touchend.  And the buttons are just elements that have listeners as well.  Those actions are fed through a couple of shader uniforms that are updated on the Javascript side, inside of RequestAnimationFrame.  In other words, the app/gpu shouldn't care (I would hope) if 1 finger, 2 fingers, or no fingers are down, it's just constantly casting the same amount of pixel rays over and over again.

Thanks again

Looking at traces, it looks like the system is under load, and threads are getting descheduled by the system (maybe thermal throttling?).

Sending to brianderson to see if there is something we look into.

Ok thank you all for taking a look :)

Dave: Is there an easy way to disable raw input events?

I spent some time looking into this, but nothing is jumping out yet that's actionable from the GPU side:
* There doesn't seem to be a large difference in average frame rate or BeginMainFrame time.
* BeginMainFrame runtime is more variable with 2 fingers, but most of that time looks like idle time.
* Both traces have an inconsistent distribution of "ProcessInputEventAck"s per frame. It's hard to tell which is worse.

It does seem like the system is under load. If it was hitting 60fps with one finger it might be barely making it. It's not with tracing enabled (and probably when using two fingers though that's hard to verify without conflating with the tracing overhead.)

I think there was a change recently where we process multiple raw input events per frame from Android rather than letting Android batch events into one for us. This would add some overhead and I do see multiple events per frame in the trace. I wonder if that's pushing us over the edge in this case.

The NextAction date has arrived: 2018-02-08

Sorry I didn't respond. The NextAction date reminded me... 

To turn off raw input events:

Turn off:

https://cs.chromium.org/chromium/src/ui/events/blink/blink_features.h?
=q=vsyncaligne&sq=package:chromium&l=12

and

https://cs.chromium.org/chromium/src/content/browser/android/content_feature_list.h?q=RequestUnbufferedDispatch&sq=package:chromium&l=15