Three.js: FPS drop with trackballControls on the new chrome on mobile.

[boulabiar]

Description of the problem

With the recent Chrome updates on mobile, the FPS drops to 2 FPS when zooming with two fingers.
The FPS for this example is around 60. it drops to 2FPS and creates saccades then get back to normal after the operation. This doesn't happen with single finger operation, only with 2 fingers zoom.
https://threejs.org/examples/misc_controls_trackball

Three.js version

• [x] r92

Browser

• [X] Chrome mobile

OS

• [x] Android

Hardware Requirements (graphics card, VR Device, ...)

[Mugen87]

I've tested the example on my Pixel with Chrome 66.0.3359.126. Although the performance monitor shows sometimes low frame rates, the experience does not feel jerky but smooth to me.

BTW: The example does not have an active render loop. This might explain the inconsistent FPS values reported by stats.js.

[boulabiar]

I've tested this on a smartphone and a tablet. As I've explained, the frame-drop only exists when using two-finger zooming.
This is what it looks like on the same version of Chrome :
https://www.youtube.com/watch?v=07VdKlSBIa4

[Mugen87]

Wow, that's definitely jerky :flushed:. Thanks for the video 👍

As I've said, I'm unable reproduce this on my smartphone. Which particular devices are you using? Besides, does this also happen with Mobile Firefox?

[boulabiar]

I have made tests on the OnePlus 3T, and Google (HTC) Nexus 9.
This only happens on the last Chrome mobile versions (at least since 2 months).
Firefox don't have these problems.

It looks like it is a common problem added to chrome.
I've tested a fix and it works. I will submit this in few hours.

[boulabiar]

I've made a fix that removed that behavior.

14017

[mrdoob]

This only happens on the last Chrome mobile versions (at least since 2 months).
Firefox don't have these problems.

Wouldn't this be a Chrome bug?

[Mugen87]

@boulabiar Do you mind reporting this here instead: https://bugs.chromium.org/p/chromium/issues/list

[boulabiar]

I reported it here:
https://bugs.chromium.org/p/chromium/issues/detail?id=841282

[boulabiar]

Can you please confirm the issue and star it on chromium?
I tested on another smartphone: Asus Zenphone 2 and it has the fps drop.

@mrdoob you have your Google pixel 9 with you? Can you please try it and confirm the issue on chromium bug reporting site?

[boulabiar]

Update: Chrome developers stated that this is a bug, but also an "intentional change".
https://bugs.chromium.org/p/chromium/issues/detail?id=841282

The bug is present and can be seen on every chrome mobile.
So in this case, what to do? Ask Chrome people to undo the policy, or update Trackball controls as they've said by adding |touch-action: none| ?

[Mugen87]

Chrome developers stated that this is a bug, but also an "intentional change".

I don't get this :thinking:

or update Trackball controls as they've said by adding |touch-action: none| ?

Can you confirm that adding this piece of CSS solves the issue?

[boulabiar]

Yes this line resolved the problem for chrome.
this.domElement.style.touchAction = 'none';

is this the file to edit to add it ?
https://github.com/mrdoob/three.js/blob/dev/src/renderers/WebGLRenderer.js

[Mugen87]

This would be the right place:

https://github.com/mrdoob/three.js/blob/a17dc8c8125aab75e25348d0aec5ab4551559b93/examples/js/controls/TrackballControls.js#L14-L15

[XanderLuciano]

The div#info was too large because it had 5px of padding and didn't use box-sizing: border-box; so the page renders 10px too wide, and because it's overflow: hidden; you never notice it.

Properly sizing the HTML elements to the window fixes this issues in all the testing I've done on android. #14622 has the modifications.

[Mugen87]

@boulabiar So although #15042 is merged, you still have the mentioned performance problem? Can you confirm that setting touchAction to none is still necessary to completely fix the issue (I refer to the proposed changes in #14182)?

[boulabiar]

yes, I confirm. The #15042 doesn't fix anything as it shows the lag in the same video pretending to fix it (1:47). A recording of the dev branch of today can be seen here too
https://www.youtube.com/watch?v=qQov0Eei_uU

Which commit is merged is not important as long as it fixes the issue and it has been around 6 months since I reported it.
So if anyone can take the change I proposed and commit it, it would be OK.

[Mugen87]

Which commit is merged is not important as long as it fixes the issue and it has been around 6 months since I reported it.

I think @mrdoob is interested in a solution that works for all controls. If TrackballControls is changed, it would be necessary to adjust other controls too in order to retain consistency. Alternatively, we could add touchAction = none; to the CSS of all examples that use TrackballControls.

[XanderLuciano]

touch-action is not supported by safari, so this would not completely resolve this issue.

MDN, caniuse

There is a bug tracker for support in safari / webkit: https://bugs.webkit.org/show_bug.cgi?id=133112

There may be other methods to prevent the zoom even though, such as:

window.addEventListener(
    "touchmove",
    function(event) {
        if (event.scale !== 1) {
            event.preventDefault();
        }
    },
    { passive: false }
);

from stack overflow.

Ideally I'd like to avoid browser specific fixes if possible.

[Mugen87]

It seems Safari will support touch-action for all platform in the upcoming months 🎉

see https://bugs.webkit.org/show_bug.cgi?id=133112#c31

[Mugen87]

FYI: touch-action is now supported in all browsers.

Besides, TrackballControls is now always created like so in the examples and thus not attached to document anymore (see #16326):

var controls = new TrackballControls( camera, renderer.domElement );

I vote to consider #16336 again. Making domElement a mandatory parameter and disallowing document as an argument should completely solve this issue for all other scenarios.

[Mugen87]

Solved via #17612