Frame rate limiting

[inodentry]

Add a way to limit the frame rate.

Ideally, allow for more flexible control over updates, to support non-game gui applications that should sleep when idle.

[alice-i-cecile]

In this discussion, I think it's important to clearly distinguish between "frame rate" (how often your screen draws), "system tick rate" (how often a given system runs) and "game tick rate" (how often the main game loop runs). I think these are all important to be able to control and limit ergonomically, but the details are a bit distinct.

Currently, as I understand it, there are three ways to tackle this sort of functionality:

1. Adding a Timer to each of the relevant criteria. Controls system tick rate.
2. The FixedTimeStep run criteria. Controls system tick rate.
3. Enabling vsync. Controls frame rate, and incidentally limits game tick rate.

(Chime in if my understanding is wrong; I haven't poked at this much myself.)

[inodentry]

"system tick rate"

This is not relevant to this issue. That's something to be discussed with Run Criteria (as you point out).

Here we are talking about the global refresh rate.

"game tick rate" is coupled with rendering frame rate, by design, so they are practically synonymous.

vsync

VSync is orthogonal. There needs to be a frame rate limiter independent of vsync. VSync is about presenting the frames with the correct timing (synchronized to the monitor), not about framerate. It is to ensure the frames are displayed correctly on the screen, without visual artifacts (tearing).

Vsync can (and preferably should, when supported; we are already doing this in bevy) be implemented in a way that does not limit frame rate. See "mailbox vsync". Also the various vendor/driver provided solutions that go by various names like "adaptive sync", "fast sync", whatever.

---

As for GUI applications, you don't want to refresh at all if there is nothing to do. Unlike games, they are mostly idle. Therefore, for proper power savings for GUI apps, there needs to be more flexible and aggressive throttle control, to only refresh when there are things to do: handle external events / input, ongoing animations, any change that needs to update the UI / screen.

[alice-i-cecile]

"game tick rate" is coupled with rendering frame rate, by design, so they are practically synonymous.

I don't think this is a particularly good design, merely a convenient one.

If we're discussing ways in which users can control and limit the performance of their game, I think that drawing this distinction and working towards the decoupling of the concepts is an important part of the puzzle.

For example, relevant to your point on non-game applications: we may want to allow the main logic loop to proceed unimpeded, while the rendering is paused completely until there is something new to draw (or the window is focused).

[cart]

Yeah I think the next step forward here is decoupling rendering from "game updates", which we have discussed a bit here: #1098 (comment)

This opens up the door to "frame rate limiting", "pipelined rendering", disabling rendering when minimized / unfocused, etc.

[Toqozz]

I'm assuming that by "decoupling rendering" you are referring to a separate render thread.

Please note that rendering in a separate thread (or in many cases, decoupling rendering in general) from game updates will inherently introduce a degree of latency:

Objects move in systems -> wait some time -> picked up by the renderer and frame is rendered with that data.

I think anything that adds latency is important to consider carefully. Personally, I feel that decoupling rendering may be over-engineering here and serves mostly to confuse users with another layer to think about.

I understand that there are advantages as well, so it may be worthwhile, but so far I don't see huge benefit.