-
Alexander Larsson authored
In commit c6901a8b, the frame clock reported time was changed from simply reporting the time we ran the frame clock cycle to reporting a smoothed value that increased by the frame interval each time it was called. However, this change caused some problems, such as: !1415 !1416 !1482 I think a lot of this is caused by the fact that we just overwrote the old frame time with the smoothed, monotonous timestamp, breaking some things that relied on knowing the actual time something happened. This is a new approach to doing the smoothing that is more explicit. The "frame_time" we store is the actual time we ran the update cycle, and then we separately compute and store the derived smoothed time and its period, allowing us to easily return a smoothed time at any time by rounding the time difference to an integer number of frames. The initial frame_time can be somewhat arbitrary, as it depends on the first cycle which is not driven by the frame clock. But follow-up cycles are typically tied to the the compositor sending the drawn signal. It may happen that the initial frame is exactly in the middle between two frames where jitter causes us to randomly round in different directions when rounding to nearest frame. To fix this we additionally do a quadratic convergence towards the "real" time, during presentation driven clock cycles (i.e. when the frame times are small). (cherry picked from commit 9ef3e700)
687b49c1