mogemimi
commented
2 months ago Thank you for asking this @seanxu973.
First of all, to directly answer your question, the frame rate control has not yet been implemented.
Originally, I used std::this_thread::sleep_for for this purpose. However, I discovered that the time precision provided by sleep_for is platform-dependent. Specifically, on Windows, it appears to rely on the Sleep() function, which can only handle time intervals in milliseconds.
- https://github.com/microsoft/STL/blob/c7c5ca7d6adde7c1554b1e52c0b97cb2a7f7ca60/stl/inc/thread#L216-L217
- https://github.com/microsoft/STL/blob/c7c5ca7d6adde7c1554b1e52c0b97cb2a7f7ca60/stl/src/sharedmutex.cpp#L40-L42
Since std::this_thread::sleep_for was not suitable for this use case, I temporarily replaced it with a simple Sleep(1). This Sleep(1) doesn’t serve any significant purpose. I should have added a FIXME or TODO comment to clarify this, and I apologize for any confusion it may have caused.
I have a few ideas for implementing synchronization for the target frame rate, and I'll experiment with them this weekend. My current plan is to use the regular Sleep() function for millisecond precision and resort to a spin-wait for the remaining microseconds. However, since spin-waiting can be power-intensive, I’ll also explore the possibility of using platform-specific instructions, such as SetWaitableTimer/WaitForSingleObject, UMONITOR/UMWAIT/TPAUSE, or similar.
Thank you for bringing this up, and I’ll keep you updated on my progress!
I noticed that the frame rate control code was replace with Sleep(1) on this commit https://github.com/mogemimi/pomdog/commit/e89c686fbf7ef8d0a39fc6ba055af2a7255d3827. I am wonndeing about the reason for this change. And should we fix it to make the set presentation interval work?