Mandate a minimum dispatch frequency for continuous UI input events #389
Description
The frequency of mousemove events is left up to the implementation. In many browsers this is usually 15-60 events per second, which can result in the pointer skipping tens or even hundreds of pixels in between consecutive events. This poses a problem for applications that need careful tracking of the mouse position, as it results in unavoidable lag that can be very noticeable to the user. (Example)
Solution: Mandate a minimum frequency of mousemove events while the pointer is moving. I would suggest 250hz. I believe this would be fast enough to eliminate all noticeable lag in most practical situations, and it would still allow for 4ms per event, which is far more than enough for any competently-designed browser to process it. (Testing on Chrome it appears to take about 0.3ms to create and dispatch most mouse events.) Going above 250hz has diminishing returns since most monitors can't refresh faster than that anyway, so this seems like a reasonable middle ground.
The same should apply to pointermove, wheel, and any other event that exists as a discretization of some continuous input from the user.