-
Zebediah Figura authored
There is no evidence that the extra overhead should matter, and this allows us to be consistent, and potentially change timeGetTime() without having to worry about quartz. On Windows, timeGetTime() has identical resolution to the interrupt time [i.e. the "InterruptTime" member of the shared user data, or QueryInterruptTime()]. Like those sources, it approximately measures the boot time. However, the values are not identical; timeGetTime() lags behind QueryInterruptTime() anywhere from 1 to 12 ms (regardless of timer period) on my Windows 10 virtual machine. The actual lag is consistent within a process but varies between runs. I have not been able to account for this lag—it's not the suspend bias, nor is it an attempt to match the tick count more closely. In short, timeGetTime() seems to be idiosyncratic to winmm. Since quartz has been shown to follow winmm exactly on Windows, let's follow it on Wine as well. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53005Signed-off-by:
Zebediah Figura <zfigura@codeweavers.com> Signed-off-by:
Alexandre Julliard <julliard@winehq.org>
2a44723d