It's relatively well known that the out-of-the-box bevy experience is not as smooth as it could be. Variable frame rates, latency, and jitter are common complaints, and those complaints have been around for years. A very quick sampling of examples:

• Res<Time> is unreliable / jittery #4669
• Variable frametime during user input #4691
• Inaccurate Time<Real>, missed FixedUpdate #21229
• Fix animation desync/jitter adsick/space-match-3#53
• Delays in user input #16335
• High input latency #21439

I spent weeks trying to get frame pacing working in bevy with something akin to https://github.com/aevyrie/bevy_framepace, but never got results as good as I knew should be possible. I could only manage to get smooth frame rates, or low CPU/GPU utilization, but not both at the same time. Nothing I came up with played well with vsync, and minimizing latency was a challenge.

The Problem

By default, bevy's render loop looks something like this (very simplified):

It's worth noting this is a very common configuration, and winit itself even recommends something like this. However:

1. The main problem with this is the vsync wait because it stalls the event loop. Naive frame pacers create the same issue by sleeping, which also stalls the event loop. When the event loop finally resumes, it then has to process a backlog of all the events that piled up while it was stalled. This creates variable amounts of work depending on how many events are queued, leading to variable frame times, stuttering, jitter, etc. (see Res<Time> is unreliable / jittery #4669 and Variable frametime during user input #4691)

2. A secondary issue with the above is the vsync wait injects time between when input events are sampled by the winit event loop, and when the results of those inputs are presented on screen. The very definition of input latency. If you get unlucky, this latency can be nearly an entire frame time. It gets worse though, because vsync typically involves double (bevy's default, I believe) or triple buffering, meaning you get a minimum of 1-3 frames worth of input latency. Even if you do everything else perfectly, the results still feel sluggish. (see Delays in user input #16335 and High input latency #21439)

Waiting in the Event Loop

Given the above, it would be nice if we could somehow move the vsync wait time into the winit event loop. That way, we can keep processing winit events right up until it's time to render the next frame. This would help address both issues:

1. We can process events while we are waiting, so the backlog of outstanding events will remain as small as possible
2. Input latency is minimized because vsync wait is kept as small as possible and inputs are more recent on average

Proof of Concept

To figure this out, I ended up building an app outside of bevy, with just winit and wgpu, but the core implementation isn't terribly complicated. Here are the important bits:

const FPS: u64 = 60;
const FRAME_TIME: Duration = Duration::from_nanos(1_000_000_000 / FPS);

pub struct App {
	render_target: Instant,
	window: Option<window>,
}

impl App {
	pub fn new() -> Self {
		Self {
			render_target: Instant::now(),
			window: None,
		}
	}
}

impl ApplicationHandler for App {
	...

	fn window_event(&mut self, _: &ActiveEventLoop, _: WindowId, event: WindowEvent) {
		match event {
			WindowEvent::RedrawRequested => {
				// TODO: run bevy schedules here

				// don't try to catch up if we're behind; just request the next frame
				let now = Instant::now();
				if self.render_target <= now {
					self.render_target = now + FRAME_TIME;
					self.window.as_ref().map(|window| window.request_redraw());
				}
			}
			_ => {}
		}
	}

	fn new_events(&mut self, _: &ActiveEventLoop, _: StartCause) {
		if self.render_target <= Instant::now() {
			self.render_target += FRAME_TIME;
			self.window.as_ref().map(|window| window.request_redraw());
		}
	}

	fn about_to_wait(&mut self, event_loop: &ActiveEventLoop) {
		// make sure we don't sleep past next render target time
		event_loop.set_control_flow(ControlFlow::WaitUntil(self.render_target));
	}
}

winit doesn't have event loop timeouts (as far as I could find), but you can emulate one with ControlFlow::WaitUntil (see rust-windowing/winit#3377). So, the pieces needed for this are:

1. The application calculates when to start rendering the next frame (render_target).
2. If there are no more events, use ControlFlow::WaitUntil to prevent sleeping past render_target (about_to_wait). Waking up triggers the next point.
3. Before the event loop handles any event, check to see if we reached our render_target time. If so, request a redraw (new_events).
4. When handling a redraw request, only request another redraw if the next render_target has already past (window_event). Prevent "catching up" by resetting render_target to now + FRAME_TIME.

And that's it. On my machine, the above resulted in ~1-2% CPU load (an 1/8th of the best I could get in bevy) and ~1% GPU load (about 1/2 of the best I could get in bevy), is buttery smooth, and input doesn't feel sluggish.

Other benefits

1. Implementing frame pacing as a bevy system means bevy has to run its schedules to find out if it should run its schedules. This necessarily means bevy will run its schedules more than is optimal. Having frame pacing be part of the event loop avoids this issue.
2. The "don't catch up" logic in window_event forces render_target to synchronize with vsync, so this works well and minimizes input latency with both vsync on and off.

Caveats

1. This needs to be implemented by bevy itself, because it involves changes to the winit event loop handler.
2. render_target should try to account for how long it takes to run the bevy schedules in the worse case. If vsync is enabled, vsync wait would consume any extra time as usual.
3. My application has low GPU load, so there may be some wrinkles to iron out when the GPU can't keep up with the target fps.
4. When using vsync, the actual refresh rate should be used instead of the hard coded 60Hz above.
5. wgpu's desired_maximum_frame_latency should be set as low as possible to minimize vsync related input latency