User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36

Steps to reproduce:

1. https://noclip.website/#smg/AstroGalaxy;AAG}F|9cpfY8@w_mUn]9cWlYp-4]JGzUiZ&7T!FSsV*T&J9x,gtT$W]p9Mj6)=bD
2. Wait for the page to load
3. Press down the left mouse button, and move the mouse

Actual results:

The movement is choppy and inconsistent

Expected results:

The movement is smooth.

It seems like events are being dropped on the floor if the page is running a bit slow.

I can repro this.

A more reduced test-case would be useful if possible, I suspect. I assume the source of the website is https://github.com/magcius/noclip.website? That makes it easier to investigate then :)

Profile on Linux (though on Linux without wayland WebGL perf sucks, and with wayland it seems something goes bananas, bug 1598967):

• No Wayland, no WebRender: https://perfht.ml/2rpCbc8
• Wayland, no WebRender: https://perfht.ml/2XHQgOk
• Wayland, Webrender: https://perfht.ml/2OH06fb

So the only meaningful profile here I guess is "Wayland, no WebRender", as otherwise the readback dominates the main thread... There we can see that most of the time in the main thread is spent in the GL calls themselves.

In my case (this is not a very fancy computer), we're missing frames all the time, but it seems that keys are responsive so it does look like we are skipping some events in between.

Only tangentially related, but in terms of reducing main-thread frame time, I guess remoting the WebGL stuff or making JS faster would be the only solution here? Jeff, is there any plan to remote WebGL to another process like bug 1548487?

When I run this test-case I get roughly the same amount of events per second (eps) in Firefox and Chrome.

• Miss frames unchecked: ~22 events per second
• Miss frames checked: ~8 events per second

Though it seems that with pointer-lock enabled (if I move my mouse while mouse-pressing) I get the same amount of frames in Chrome, but ~6 events when missing frames in Firefox.

Not sure if that explains the choppiness itself, or we're just missing more (content-process main-thread) frames because of WebGL perf / WebGL running on the main thread except than on the GPU process. A profile on Windows would be interesting.

Questions for reporter:

• If you have the time, could you take a profile in your machine with https://profiler.firefox.com and share it here?
• I see there is code in the repo to avoid taking the pointer lock, and using pageX / pageY instead of movementX / movementY (link. Does using that code provide a measurable improvement on Firefox out of curiosity? That'd discard the "we're just spending more time on the main thread" hypothesis :)

Also, thanks for filing the bug, and that is a pretty cool website :)

You can enter main.viewer.inputManager.usePointerLock = false in the dev tools Console to try it. It makes dragging pretty smooth for me. I'll have a profiler for you shortly.

Here's a profile on Windows. https://perfht.ml/2OiJyLQ

Something a bit unexpected with that profile. It has two child processes spending lots of time.

(Moving a bit better component)

Here's a repro that happens without WebGL. Not that I think WebGL performance cannot be improved, but it is a separate bug and let's treat it separately.

https://jsbin.com/lopalarala/edit?html,js,output

Yes, bug "webgl-ipc" could help with moving GL execution off the main thread.

The priority flag is not set for this bug.
:hsinyi, could you have a look please?

For more information, please visit auto_nag documentation.