https://bugs.winehq.org/show_bug.cgi?id=57442 William Horvath <wine(a)horvath.blog> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wine(a)horvath.blog --- Comment #1 from William Horvath <wine(a)horvath.blog> --- Regression commit: 54ca1ab607d3ff22a1f57a9561430f64c75f0916 "win32u: Simplify the logic for driver messages polling." I noticed this issue from a PeekMessage event loop like this: while (running) { while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)) { if (msg.message == WM_QUIT) { running = false; break; } TranslateMessage(&msg); DispatchMessage(&msg); } if (running) { QueryPerformanceCounter(¤t_time); double elapsed = get_ms_delta(last_check, current_time); if (elapsed >= 0.1) /* 10kHz */ { process_key_state_changes(); last_check = current_time; } Sleep(0); } } If driver events (e.g. mouse motion, keypresses) are sent at a freq. greater than 1000hz, the processing loop above only receives them in ~10ms intervals on average, because most seem to be entirely dropped. If the events are sent at a freq. less than or equal to 1000hz, then there's barely any added delay (~0.1ms), and all of them are received, same as before the regression commit. I only tested with `GetKeyboardState` + an external program sending X11 key events at a constant rate, but reverting the mentioned commit allows even 0.25ms keypress intervals (8000hz) to all be received with minimal delay. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.