Open Bug 1434231 Opened 3 years ago Updated 2 years ago

Long time interval between mousemove events

Categories

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

59 Branch
Unspecified
Windows
defect

Tracking

()

UNCONFIRMED

People

(Reporter: robbendebiene, Unassigned)

Details

Attachments

(2 files)

Attached image 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)
Component: Untriaged → Event Handling
Product: Firefox → Core
OS: Unspecified → Windows
Attached file 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.
Priority: -- → P2
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?
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)
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?
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.
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.