boulabiar@ -- Thanks for reporting this issue. Tested on Chrome #66.0.3359.158 using Pixel 2 XL Android 8.1.0 and observed that there is no fps drop by following the below steps:

1. Launched Chrome.
2. Navigated to the URL - https://threejs.org/examples/misc_controls_trackball
3. Zoomed the screen using 2 fingers.
4. Observed that FPS is almost maintained.

Could you please share the values of the FPS to be maintained soon after zooming in. Also, tested on Chrome #60.0.3072.0 and it almost behaved the same.

Attached the screen cast for reference and let us know if we have missed anything.

Could you also share the device details including OS build number where the issue is reproduced.

Thanks in advance! 

Deleted: 841282.mp4 2.1 MB

	841282.mp4 2.1 MB View Download

In the video I've recorded, I zoom with two fingers a lot of times and without interruption. Try do do the same as me.
You almost got the frame drop in your own video but you did small gestures so they got not noticed.
With big pinch/zoom the fps can go down to 5 or 2 fps! 

I've tested this on another device: 
Asus Zenfone 2. Android 6.0.1. Chrome 66.0.3359.158

These are now 3 different devices with the same problem.

Thank you for providing more feedback. Adding the requester to the cc list.

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

Reporter can you give me a little background on what that library does with the input so I can better understand the problem? Are you listening to the touchevents or pointerevents? Are you doing all pinch zooming logic yourself or do you depend on browser pinch zoom?

The rendering is made with Three.js (WebGL).
The input is handled through TrackballControls.js which uses the usual touchevents:
domElement.removeEventListener( 'touchstart', touchstart, false );
domElement.removeEventListener( 'touchend', touchend, false );
domElement.removeEventListener( 'touchmove', touchmove, false );

The zoom/pinch logic is handled inside the library depending on  event.touches.length (2 or more is zoom/pinch)
(dx = event.touches[ 0 ].pageX - event.touches[ 1 ].pageX)


Please note that this example worked perfectly with previous chrome versions, and it still works perfectly on other browsers like firefox.

Thank you for providing more feedback. Adding the requester to the cc list.

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

boulabiar@, it looks like Chrome thinks it's scrolling/zooming - this causes it to not schedule work by the page to maintain a low input latency. This is a recent change to our scheduling behavior.

There's some improvements we could make here: not starting a PinchGesture at all if it can't possibly change the page scale (user-scrollable=no). However, the issue is still present as the page has just a few pixels of scrolling (at least on my screen) so I can reproduce the frame rate drops by single touch dragging.

The root issue here is that you're not telling the browser that you handled the touches. The issues should go away if you call `event.preventDefault()` in your touch handlers. This tells the browser that the touch was consumed by your application and that the browser shouldn't try to scroll or zoom as a result of that touch.

Thanks for the comment and confirming the bug.
Actually, event.preventDefault() is called in the touchmove function

function touchmove( event ) {
  event.preventDefault();
  event.stopPropagation();

which is then used for touch handeling
this.domElement.addEventListener( 'touchmove', touchmove, false );

It seems that the new policy with the additions to addEventListener api is to ignore the preventDefault function when the listener is not considered passive.
I've tried adding the event listener as passive and the problem disappeared.
addEventListener( 'touchstart', touchstart, { passive: false } );)
(this is only for chrome)

BUT, as the behavior is not the same as it was before, and it is not the same as in other browsers (firefox). This looks more like a regression.
(I think api additions to addEventListener should not break old behaviors)

Ah, yes, this is an intentional change, see: https://developers.google.com/web/updates/2017/01/scrolling-intervention

Ideally, you should add |touch-action: none| to your page.