Haven’t tested yet, but there may be an issue with a long term run of the sample C++ RunEventLoop. A slight time delay may be incurred when issuing sleep_for that may cause the loop to run fewer than 60 frames per second. Using sleep_until would fix the issue.
Hi @abdulgkhan. Thanks for your feedback!
In general a lot of our code snippets are simplistic in order to demonstrate the use of our APIs in a concise way rather than be opinionated on how to implement a game loop, for example.
It is true, however, that this example is a little naive in how it schedules the next frame and that potential delays from the sleep_for call could accumulate.
There are different approaches to implementing frame scheduling for event/ game loops so we simply recommend taking our code snippet as “example only” and implementing whatever behaviour you want in your use case.
Thanks for fixing the example! I gave it a whirl and noticed that the duration “Rep” template type is an integral number of ticks, so double as a template parameter did not compile using clang. Converting frames per second into a nanosecond period gives precise frame rates for rates that are simple decimal divisors. For repeating fractions it takes around a year before the system becomes a frame behind schedule due to rounding.
To avoid the compilation error:
I would change
static const std::chrono::duration kFramePeriodSeconds(1. / static_cast<double>(kFramesPerSecond));
static const std::chrono::nanoseconds kFramePeriodSeconds((long long)(1000000000.0/kFramesPerSecond));