Currently, the rawinput thread either incorrectly spreads the timestamps over idle time if the poll interval is less than 100ms, and abruptly switches to lumping all accumulated inputs to happen simultaneously if it exceeds 100ms.
This means that any game which implements retroactive event handling based on timestamps will jarringly snap between the two polar opposite extremes of incorrect behaviour.
This PR replaces the arbitrary 100ms threshold with logic based on measuring the idle start and end time.
If the thread was idle for more than 125000 nanoseconds, it is considered to have not had any input in its queue before it entered idle.
p.s. @slouken I have some ideas about potential timing bugs that I suspect might be the root cause of certain class of symptoms being reported about CS2, but I can’t be sure just by inferring from behaviour. How would you suggest me going about getting in touch with those responsible?
Currently, the rawinput thread either incorrectly spreads the timestamps over idle time if the poll interval is less than 100ms, and abruptly switches to lumping all accumulated inputs to happen simultaneously if it exceeds 100ms.
This means that any game which implements retroactive event handling based on timestamps will jarringly snap between the two polar opposite extremes of incorrect behaviour.
This PR replaces the arbitrary 100ms threshold with logic based on measuring the idle start and end time.
If the thread was idle for more than 125000 nanoseconds, it is considered to have not had any input in its queue before it entered idle.
p.s. @slouken I have some ideas about potential timing bugs that I suspect might be the root cause of certain class of symptoms being reported about CS2, but I can’t be sure just by inferring from behaviour. How would you suggest me going about getting in touch with those responsible?