On Thu Jul 11 12:51:07 2024 +0000, Tatsuyuki Ishi wrote:
Both a clean revert or removing the CLOCK_REALTIME coarse path are reasonable ways to achieve the goal. We can go for endless bikeshed but the outcome is the same. I've provided sufficient justification in the commit message. If you want to craft a test case, you can do one by measuring the accuracy of NtDelayExecution. BTW, one of the reason I want this is because I want count on NtDelayExecution being accurate on Wine (but not on Windows). I'm developing a frame limiter specific for Proton use and that allows me to accurately sleep without all the redundant spinning to compensate for native Windows' poor timer accuracy.
@ishitatsuyuki Using a real-time clock to limit frame time is not a rational solution. In such cases, use CLOCK_MONOTONIC. CLOCK_MONOTONIC is used by all graphics libraries. The real time clock can change the time abruptly, for example in the case of time adjustment via NTP, hence you can get unpredictable behavior in your code. Also, the real time clock has a higher overhead. In your comment to the commit, I don’t see any tests, I only see that you came up with the need for such a solution in Wine. Therefore, I ask you to provide tests.