https://bugs.winehq.org/show_bug.cgi?id=57442
--- Comment #6 from Rémi Bernon rbernon@codeweavers.com --- We cannot really use the message count as a throttle anymore because of how peeking for messages have been optimized. Restoring it is pretty much the same as removing the throttle entirely, and it puts the load on the X server. It's maybe that visible, but it definitely adds some load, and makes a difference in various cases.
The calls to peek_message are now extremely fast, as in the most common case it's just about checking for bits in shared memory with wineserver, and the 200 message count (actually more a peek_message call counter) throttle isn't very effective.
That limit would need to be increased accordingly, but using a time based throttle is more deterministic, and yes NtQueryPerformanceCounter could be an option.
The proper way to support such high-frequency X11 input events is to wait for them instead of doing that polling we do, but that requires another large architectural redesign.
The input events have to go through wineserver, and with very high frequency input, receiving them in the application process just to route them through wineserver is inneficient, which is why I think it should instead be done in wineserver. There, they could be waited for, and it would save a lot of IPCs (replacing X -> app -> wineserver -> app, with X -> wineserver -> app).