This is something I've noticed when investigating Smoothness benchmark regressions on Windows triggered by a preliminary fix  crbug.com/487724 .
Currently the delay to flush input events is fixed and 16666 us which corresponds to 60 Hz framerate.

On Windows this task is scheduled via MessagePumpForUI which means the delay depends on the system clock resolution. Typically the delay would be greater, up to 1 ms late in most cases and sometimes even later. Scheduling each next delay 16666 from the previous wake-up time would very likely result in drifting the flush time relative to the desired framerate.

I did some experiments in which I saw a correlation of smoothness.top_25_smooth benchmark results with the kFlushInputRateInUs delay:
- percentage smooth improves with the shorter delay
- frame times get worse with the longer delay
- main_thread_scroll_latency_discrepancy gets worse withe shorter delay and improves with the longer delay.

I tried implementing the variable delay and it seemed to slightly improve a few the metrics mentioned above. More specifically the percentage_smooth improved by 2.5%. That isn't a significant improvement but I thought it is better to have before I try to make other message pump changes.