1434231 - Long time interval between mousemove events

Status: UNCONFIRMED

(Core :: DOM: UI Events & Focus Handling, defect, P2)

Description

[robbendebiene]

Attachment: Drawing in FF 59

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20180128191252

Steps to reproduce:

Open https://codepen.io/anon/pen/gvbMOW and move your mouse as fast as possible over the canvas, while holding the left mouse button. Using Firefox 58, you will see pretty smooth lines (for me the average time lies between 2-3ms).


Actual results:

Using the latest Firefox 59, the lines won't be nearly as smooth as they are in Firefox 58 (see screenshot). This is because the average time between the mouse events increases up to 17-32ms. If I would have to make an educated guess I would say this looks like throttling the events to the frame rate / fps (in other words: input handler debouncing)

Comment 1

[Andreas Farre [:farre]]

Attachment: pointer.html

(In reply to robbendebiene from comment #0)
> Using the latest Firefox 59, the lines won't be nearly as smooth as they are
> in Firefox 58 (see screenshot). This is because the average time between the
> mouse events increases up to 17-32ms. If I would have to make an educated
> guess I would say this looks like throttling the events to the frame rate /
> fps (in other words: input handler debouncing)

This is a feature introduced in Bug 1361067 and turned on in Bug 1392876, so yes debouncing, but also aligning events to frames. This is as it should, but what's lacking is the fact that the actual coalescing isn't functioning as can be seen in the test I attached. Trying it out in Chrome show the "missed" pointer events happening more regularly.

Even though an event every 2ms won't ever happen we should definitely do better than this.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Most of the input event handling latency comes from the setup refreshdriver is triggered. 

Locally when testing Nightly vs. Chrome the test reports ~16ms in both cases as the average time between events.
(Perhaps this machine is too fast or something.)

Anyone who can see, want to play with input_event_queue.* prefs?

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

oh, and I was testing the link in comment 0, but testing the pointer.html, I still see almost identical behavior in Nightly and Chrome(dev)

Comment 4

[Andreas Farre [:farre]]

What I tried to get at in the test is to by over-extending every tenth rAF-callback to get more than one coalesced event. That happens in chrome but not in my nightly. If you fiddle with the botch function to delay more it might become more visible?

Comment 5

[Andreas Farre [:farre]]

So I expect us to only handle am event at most every 16ms, but when a paint is delayed for more than a couple of frames I expect to see more coalesced events.