Support for mousemove and other continuous events

[bennym7n]

This API currently doesn't support "continuous" events like mousemove. These events can be especially performance-sensitive since they often dispatch in rapid succession, so it would be helpful to be able to measure their end-to-end latency.

[Nicolás Peña Moreno]

What are some concrete use-cases for this?

[bennym7n]

Selecting text with the mouse in Google Docs is done with an event handler on mouse move; if the mouse is over a new location in the document, some work will be done to visually update the selection. This API could help identify cases where this performs poorly.

[Nicolás Peña Moreno]

Ahh I see thanks for sharing! Out of curiosity, do you currently measure this right now? If so how?

[bennym7n]

Yes, we measure this for mousemove events that result in a selection change. We post a message to a message channel in the animation frame following these events, and when that message is processed, we measure the current time, which we know is after browser rendering has completed. Then we take the difference between that time and the event's timestamp, to get a full end-to-end number.

The problem with this approach is that we don't have a guarantee that the message callback is the first task to run after the animation frame (like requestPostAnimationFrame would provide). Sometimes that callback won't be run for several more frames. So we end up frequently over-estimating the end-to-end latency.

[Michal Mocny]

A few new techniques are available now (or soon) which were not available when this was requested:

• You can measure long animation frames with LoAF api, which will let you know exactly how long it took (on main thread) to produce a frame, if that frame took more than 50ms. This would let you know about outlier cases where things janked up significantly, without needing to measure every single frame (mousemove can fire very often).
• If you want to explicitly measure as you mentioned: rAF + postMessage (i.e. a setImmediate polyfill) you can now do that with scheduler.postTask which supports higher priority task scheduling, or (soon) scheduler.yield which supports "push to front" semantics of scheduling.

Both of those approaches I think allows you to manually measure long mousemoves without having to measure every single mousemove with event timing.

It might be possible to report these types of continuous events only for cases where they are excessively long (i.e. maybe not allow a custom durationThreshold?) but I think it would be quite noisy and fill event timing buffers to add such events to the list of supported event types.