xrConvertWin32PerformanceCounterToTimeKHR returns the wrong XrTime
Using the Oculus runtime, xrConvertWin32PerformanceCounterToTimeKHR() appears to have a bug (at least on my system).
QueryPerformanceFrequency() returns 10000000 (1e7) on my machine, while XrTime is in nanoseconds. So intervals expressed in XrDuration should always be exactly 100 times larger than the corresponding differences between values reported by QueryPerformanceCounter().
On my machine, instead, intervals computed from the XrTime values given by xrConvertWin32PerformanceCounterToTimeKHR() are always exactly 10 times larger than the differences in QPC values.
The bug might have gone unnoticed because the absolute value of XrTime computed by xrConvertWin32PerformanceCounterToTimeKHR() is more or less 100 times larger than the QPC value (something like 99.9945 at application start), but when you compute differences between successive calls it's clear that the relative times are off by a factor of 10.
The same function works correctly with the Microsoft WMR runtime: both absolute times and intervals are exactly 100 * QPC values.
QueryPerformanceFrequency() returns 10000000 (1e7) on my machine, while XrTime is in nanoseconds. So intervals expressed in XrDuration should always be exactly 100 times larger than the corresponding differences between values reported by QueryPerformanceCounter().
On my machine, instead, intervals computed from the XrTime values given by xrConvertWin32PerformanceCounterToTimeKHR() are always exactly 10 times larger than the differences in QPC values.
The bug might have gone unnoticed because the absolute value of XrTime computed by xrConvertWin32PerformanceCounterToTimeKHR() is more or less 100 times larger than the QPC value (something like 99.9945 at application start), but when you compute differences between successive calls it's clear that the relative times are off by a factor of 10.
The same function works correctly with the Microsoft WMR runtime: both absolute times and intervals are exactly 100 * QPC values.