1289403 - [e10s] PointerLock works very slow on Nightly and Aurora with this site http://mdn.github.io/pointer-lock-demo/

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect, P2)

Description

[ovidiu boca[:Ovidiu]]

[Affected versions]:
- Nightly 50.0a1
- Firefox Developer Edition 49.0a2

[Affected platforms]:
- All

[Steps to reproduce]:

1.  Launch the latest Nightly
2.  Navigate to the simple pointer lock demo: http://mdn.github.io/pointer-lock-demo/
3.  Click on the canvas area and move your mouse


[Expected result]:

The ball movements should be smooth. 

[Actual result]:

The ball movements are very choppy. 

[Note]:

This is an e10s issue, because after I tested this issue on FF Nightly with e10s disabled everything worked as expected. 
On Windows this issue is less visible than Mac and Ubuntu.

Comment 1

[Xidorn Quan [:xidorn] UTC+10]

I believe this is bug 1255338. But currently I'm not actively working on that unfortunately...

Comment 2

[Andrew Overholt [:overholt]]

Xidorn, bug 1255338 is e10s HiDPI Linux-specific and comment 0 says that this affects OS X so is this really that bug?

Jim, who's making quality decisions on e10s?

Comment 3

[Xidorn Quan [:xidorn] UTC+10]

Bug 1255338 affects all desktop platforms. On platforms other than e10s HiDPI Linux, it is "just" a performance issue, however, on that specific platform, it is a correctness issue.

Comment 4

[Jim Mathies [:jimm]]

(In reply to Andrew Overholt [:overholt] from comment #2)
> Xidorn, bug 1255338 is e10s HiDPI Linux-specific and comment 0 says that
> this affects OS X so is this really that bug?
> 
> Jim, who's making quality decisions on e10s?

The team and product. As long as there aren't any needinfos it'll fall into our triage list for our Thursday standup.

FWIW that demo works fine on my Windows system. We can check it on mac and linux too.

Comment 5

[Tracy Walker [:tracy]]

Win 7 (VM), Nightly, 51.0a1, 20160802030437 - Bug 1255338
Mac 10.11, Nightly, 51.0a1, 20160802030437 - Perf issue, this bug report (and sometimes bug 1255338)
Ubuntu 14.04(VM), Nightly 51.0a1, 20160802030437 - Bug 1255338

In e10s and non-e10s window (though I am suspect about the VM involvement), I observe bug 1255338 (the red dot just flies about the canvas on mouse movement) on Win 7 (VM) and Ubuntu 14.04 (VM) with the VM on external monitor or on host machine retina display. Because of that broken behavior, it is not possible to tell if this bug is affecting those platforms.  

I have also seen bug 1255338 on Mac 10.11 but only occasionally by moving the tab containing the pointerlock test page from external monitor to the MBP Retina display, then controlling the red dot with mouse. Most of the time, on Mac, the demo works, though the test quickly consumes resources to the point that movement of the red dot becomes quite jumpy (this bug). The performance bug only appears to seriously affect e10s.

Comment 6

[Xidorn Quan [:xidorn] UTC+10]

(In reply to Tracy Walker [:tracy] from comment #5)
> Win 7 (VM), Nightly, 51.0a1, 20160802030437 - Bug 1255338
> Mac 10.11, Nightly, 51.0a1, 20160802030437 - Perf issue, this bug report
> (and sometimes bug 1255338)
> Ubuntu 14.04(VM), Nightly 51.0a1, 20160802030437 - Bug 1255338
> 
> In e10s and non-e10s window (though I am suspect about the VM involvement),
> I observe bug 1255338 (the red dot just flies about the canvas on mouse
> movement) on Win 7 (VM) and Ubuntu 14.04 (VM) with the VM on external
> monitor or on host machine retina display. Because of that broken behavior,
> it is not possible to tell if this bug is affecting those platforms.  

Testing pointerlock in VM is tricky. VMs usually follow the cursor of host, and never feedback the change to pointer position to the host, so that in normal cases, the cursor can move more smoothly. For VMware, you need to open Preferences / Input, and set "Optimize mouse for games" to "never" to have this work properly.

This issue is due to interaction between any non-game and VMs, and is actually not in the scope of bug 1255338.

Comment 7

[Xidorn Quan [:xidorn] UTC+10]

(In reply to Tracy Walker [:tracy] from comment #5)
> I have also seen bug 1255338 on Mac 10.11 but only occasionally by moving
> the tab containing the pointerlock test page from external monitor to the
> MBP Retina display, then controlling the red dot with mouse. Most of the
> time, on Mac, the demo works, though the test quickly consumes resources to
> the point that movement of the red dot becomes quite jumpy (this bug). The
> performance bug only appears to seriously affect e10s.

It's weird that it "consumes resources ... movement of the red dot becomes quite jumpy". The resource consumption should be consistent, although it is much higher on e10s then non-e10s.

Comment 8

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Hi Jim, given that the meta bug 124037 is planned for Fx50, should we work on a fix for this soon'ish and target to land in Aurora50?

Comment 9

[Xidorn Quan [:xidorn] UTC+10]

I guess you provided a wrong meta bug.

I think this bug depends on (and is probably just a duplicate of) bug 1255338. And bug 1255338 is definitely not upliftable, because it would be quite a bit of refactor.

Comment 11

[Xidorn Quan [:xidorn] UTC+10]

FWIW, the pointer-lock-demo on MDN is poorly coded. The demo iteself, not our implementation, is responsible to the performance issue, since it could hook tons of rAFs in one frame.

I have submitted a pull request to fix that: https://github.com/mdn/pointer-lock-demo/pull/3

Comment 12

[Xidorn Quan [:xidorn] UTC+10]

Ovidiu, could you confirm that there is no longer any performance issue with pointer-lock-demo after my pull request merged?

Comment 13

[ovidiu boca[:Ovidiu]]

I tested this issue with FF 52, 51, 50 and 49. The problem doesn't reproduce any more.

Comment 14

[Xidorn Quan [:xidorn] UTC+10]

Thanks for verifying. Let's say this bug itself is fixed as the demo is fixed.

Comment 15

[ovidiu boca[:Ovidiu]]

I think that's a good idea.