[PATCH 0/1] MR7005: win32u: Check for driver events more often.

[William Horvath (＠whrvth)]

Use a QPC wrapper to avoid NtGetTickCount, which is coupled to the 16 millisecond user_shared_data_timeout in server/fd.c. This sets the throttling period to 1ms, as originally intended.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57442

[PATCH 1/1] win32u: Check for driver events more often.

[William Horvath]

From: William Horvath

Use a QPC wrapper to avoid NtGetTickCount, which is coupled to
the 16 millisecond user_shared_data_timeout in server/fd.c. This
sets the throttling period to 1ms, as originally intended.

Fixes: 54ca1ab6
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57442
---
 dlls/win32u/message.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/dlls/win32u/message.c b/dlls/win32u/message.c
index ef8b6f86431..775188b379b 100644
--- a/dlls/win32u/message.c
+++ b/dlls/win32u/message.c
@@ -3059,14 +3059,22 @@ static HANDLE get_server_queue_handle(void)
     return ret;
 }

+/* 1ms-resolution tick for throttling driver event checks */
+static inline DWORD get_millisecond_tick(void)
+{
+    LARGE_INTEGER counter;
+    NtQueryPerformanceCounter( &counter, NULL );
+    return counter.LowPart / 10000;
+}
+
 /* check for driver events if we detect that the app is not properly consuming messages */
 static inline void check_for_driver_events(void)
 {
-    if (get_user_thread_info()->last_driver_time != NtGetTickCount())
+    if (get_user_thread_info()->last_driver_time != get_millisecond_tick())
     {
         flush_window_surfaces( FALSE );
         user_driver->pProcessEvents( QS_ALLINPUT );
-        get_user_thread_info()->last_driver_time = NtGetTickCount();
+        get_user_thread_info()->last_driver_time = get_millisecond_tick();
     }
 }

@@ -3108,7 +3116,7 @@ static DWORD wait_message( DWORD count, const HANDLE *handles, DWORD timeout, DW
     }

if (ret == WAIT_TIMEOUT && !count && !timeout) NtYieldExecution();
-    if (ret == count - 1) get_user_thread_info()->last_driver_time = NtGetTickCount();
+    if (ret == count - 1) get_user_thread_info()->last_driver_time = get_millisecond_tick();

KeUserDispatchCallback( &params.dispatch, sizeof(params), &ret_ptr, &ret_len );

[Rémi Bernon (＠rbernon)]

Rémi Bernon (@rbernon) commented about dlls/win32u/message.c:
>  return ret;
>
> }
>
> +/* 1ms-resolution tick for throttling driver event checks */
> +static inline DWORD get_millisecond_tick(void)
> +{
> - LARGE_INTEGER counter;
> - NtQueryPerformanceCounter( &counter, NULL );
> - return counter.LowPart / 10000;
>
> +}
> -

Fwiw I think we could increase the check frequency a bit, as there's indeed now some higher polling rate input devices out there. Something like this maybe?

```suggestion:-7+0
/* get driver event check time for throttling */
static inline DWORD get_driver_check_time(void)
{
    LARGE_INTEGER counter, freq;
    NtQueryPerformanceCounter( &counter, &freq );
    return counter.QuadPart * 8000 / freq.QuadPart; /* 8kHz */
}

```

[William Horvath (＠whrvth)]

On Thu Dec 12 10:38:00 2024 +0000, Rémi Bernon wrote:
> Fwiw I think we could increase the check frequency a bit, as there's
> indeed now some higher polling rate input devices out there. Something
> like this maybe?
> /* get driver event check time for throttling */
> static inline DWORD get_driver_check_time(void)
> {
>     LARGE_INTEGER counter, freq;
>     NtQueryPerformanceCounter( &counter, &freq );
>     return counter.QuadPart * 8000 / freq.QuadPart; /* 8kHz */
> }

I was just playing it safe; I wasn't sure at what frequency the X server overhead you mentioned became a concern. If 8000hz is under that threshold, I entirely agree with that suggested value.

Otherwise, why do we need to worry about `freq` if it's hardcoded to TICKSPERSEC = 1ms? I see a lot of other occurrences where we pass NULL here.

[Rémi Bernon (＠rbernon)]

On Thu Dec 12 10:46:06 2024 +0000, William Horvath wrote:
> I was just playing it safe; I wasn't sure at what frequency the X server
> overhead you mentioned became a concern. If 8000hz is under that
> threshold, I entirely agree with that suggested value.
> Otherwise, why do we need to worry about `freq` if it's hardcoded to
> TICKSPERSEC = 1ms? I see a lot of other occurrences where we pass NULL here.

It's hardcoded right now and unlikely to change but I think this is a ntdll implementation detail and we shouldn't let the assumption spread.

Yes I think 8khz should be fine, it was a problem when we were spinning on X calls (maybe even the yield would be enough, but not completely sure).