[Merged by Bors] - Update time by sending frame instant through a channel

[hymm]

Objective

• The time update is currently done in the wrong part of the schedule. For a single frame the current order of things is update input, update time (First stage), other stages, render stage (frame presentation). So when we update the time it includes the input processing of the current frame and the frame presentation of the previous frame. This is a problem when vsync is on. When input processing takes a longer amount of time for a frame, the vsync wait time gets shorter. So when these are not paired correctly we can potentially have a long input processing time added to the normal vsync wait time in the previous frame. This leads to inaccurate frame time reporting and more variance of the time than actually exists. For more details of why this is an issue see the linked issue below.
• Helps with Res<Time> is unreliable / jittery #4669
• Supercedes move time update to after everything #4728 and update time in render stage #4735. This PR should be less controversial than those because it doesn't add to the API surface.

Solution

• The most accurate frame time would come from hardware. We currently don't have access to that for multiple reasons, so the next best thing we can do is measure the frame time as close to frame presentation as possible. This PR gets the Instant::now() for the time immediately after frame presentation in the render system and then sends that time to the app world through a channel.
• implements suggestion from @aevyrie from here move time update to after everything #4728 (comment)

Statistics

---

Changelog

• Make frame time reporting more accurate.

Migration Guide

time.delta() now reports zero for 2 frames on startup instead of 1 frame.

[hymm]

please ignore that my stats have a higher standard deviation than in #4735. I ran the other branches too and they also had a higher standard deviation. Seems to just be weirdness of testing on different days.

[superdump]

We’ve been discussing ways of feeding back data from the render world to the main world, especially when pipelining is fully working, and keeping the latency low as rendering of frame n will happen in parallel with simulation of frame n+1.

I proposed use of channels for this where sometimes you just want to get the value back at some point, asynchronously, and other times you want to make simulation of the next frame wait on the current frame so you could have a system that blocks on receiving something over a channel. The latter serialises the pipelining again somewhat, but maybe some use cases require it.

For this case, not blocking is the right choice as time measurement is such a fundamental piece, it happens after present, and if we blocked then it would basically make pipelining useless.

I don’t remember how Unity solved time measurement with as pipelined renderer, I need to reread the article, but the odd thing in my mind is that if we use the presentation time for a previous frame, what does that tell us about the difference in presentation times for the previous and current frame? We’re assuming that the frame rate will be consistent. Maybe that’s the best we can do?

And when we have pipelining, the time in the channel would likely be a measurement from two frames ago because we’re simulating n+1, n is being rendered and hasn’t been presented yet, and n-1 has been presented. What impact fires that have?

I think this PR is probably a great step, just noting some thoughts on the end goal, and maybe they’ve already been discussed…

[hymm]

We’re assuming that the frame rate will be consistent. Maybe that’s the best we can do?

I think this is right. The ideal would be to say that the current frame is going to be presented in x milliseconds and use that time, but needs new apis to do. KhronosGroup/Vulkan-Docs#1364 is this api. We could potentially experiment with android as there is an api available on some devices that that new api is based on. https://www.khronos.org/registry/vulkan/specs/1.3-extensions/man/html/VK_GOOGLE_display_timing.html

We can also potentially get the actual presentation time from the graphics card, but this is only currently available on windows.
https://docs.microsoft.com/en-gb/windows/win32/api/dcomp/nf-dcomp-idcompositiondevice-getframestatistics

[inodentry]

While this is indeed a significant and welcome improvement to Bevy's timing consistency, I don't think issue #4669 should be closed by it. The problem is not "resolved" and there is still room for improvement.

[IceSentry]

I can't comment on the impact of the change, but the code looks correct to me.

[alice-i-cecile]

Some documentation nits, but I'm in favor of this approach. The arguments are solid, and the improvements look good.

[ciwolsey]

I used to experience a lot of stutters and timing issues but since I've been using this things have been much smoother. It's all very subjective (I have no statistics to back this up) but I'm eager to see this merged. Great work.

[superdump]

Mostly looks ok and so I only have minor requests below.

I'm still not convinced by using just a sampled point in time as the reference time for simulating and rendering the next frame which will be presented at a later point in time, but that is not a regression introduced by this PR and this PR brings other significant benefits regarding consistency.

[cart]

This looks good to me. I'm sure this will change in the future as we add pipelining and framepacing, but thats a conversation for another day. Great work!

[cart]

bors r+

[bors]

Pull request successfully merged into main.

Build succeeded:

• build-and-install-on-iOS
• build-android
• build (nightly, ubuntu-latest)
• build (stable, macos-latest)
• build (stable, ubuntu-latest)
• build (stable, windows-latest)
• build-wasm (nightly, ubuntu-latest)
• build-wasm (stable, ubuntu-latest)
• check-compiles
• check-doc
• check-missing-examples-in-docs
• ci
• markdownlint
• miri
• run-examples
• run-examples-on-wasm
• run-examples-on-windows