Frame limiter setting

[NimbusHeartstriker]

Is your feature request related to a problem? Please describe.

Resonite's current visual system makes absolute full use of your graphics card, even when the application is run in desktop mode and is minimized! This makes it so that if you want an application to have more power, it must be the active window.

Describe the solution you'd like

This feature request seeks to ask for a way to manually limit the number of frames generated per second, anywhere from 15 to 120 frames per second- or a checkbox to disable the feature entirely and use default (unlimited) frame cap.

I think this feature would be really nice so programs like blender don't have to be the active window in order to get a reasonable amount of your GPU's proccessing power while Resonite is not your active window.

This feature will also introduce stability amongst your frames- say if your natural frame limit is 120, but looking at a mirror reduces it to 60, means you will experience a constant and smooth frames at all times if you set your frame limit to sixty- that is to say, you will not experience frame drops unless your frames would lower below 60 frames per second.

Describe alternatives you've considered

I haven't thought of any others, but pausing Resonite's rendering entirely while the application is minimized would be a good idea as well.

Additional Context

No response

[shiftyscales]

For VR- the frame limit/refresh rate is controlled by the compositor, e.g. SteamVR- and in the per-application video settings, you can clamp to a lower multiple of the display's refresh refresh rate, e.g. a 45 FPS lock for a 90Hz headset.

For desktop use- my recommendation in the interim would be to either make use of existing frame limiters in your graphics driver, or to make use of external frame limiters such as MSI Afterburner/Rivatuner Statistics Server (RTSS).

Addition of new settings is currently blocked by #584. I'd suggest you also check out and contribute to the discussions over at #614, @NimbusHeartstriker.

[shiftyscales]

Marking this issue as unblocked since the new settings menu was implemented.

[Frooxius]

This might be implemented in 2024.5.3.467! I've added option to limit the framerate while in background.

I'm not sure if that's exactly what you're asking for or not. From the sound of it it seems it's what it is?

Could you please clarify?

[shiftyscales]

@Frooxius - From my reading of the issue, while they had mentioned limiting the background framerate, they also had use-cases that involved limiting the focused framerate, e.g.:

This feature will also introduce stability amongst your frames- say if your natural frame limit is 120, but looking at a mirror reduces it to 60, means you will experience a constant and smooth frames at all times if you set your frame limit to sixty- that is to say, you will not experience frame drops unless your frames would lower below 60 frames per second.

---

Having a focused/active framerate cap is still useful as its own separate feature for both power saving reasons (e.g. clamping the framerate on laptops to minimize heat production/energy usage), as well as frame rate stability reasons (capping the framerate below a value you can fairly consistently hit so the frame pacing is smoother.)

Capping framerates to ensure the GPU is not pinned to 100% can also reduce latency.

[Frooxius]

Hmm I, suppose that means they want foreground one? I'd prefer them to answer here though before comitting more work.

None of the usecases seem good to me here:

• Power saving is usually done by laptop itself, the OS will be limiting the frame rate externally.
• Limiting framerate can actually cause pacing issues based on Unity documentation. For background we don't care, but if your goal is to have better pacing, then it causes issues
• Limiting framerate will always increase latency, it will never decrease it. Framerate os limited by adding additional delays (latency) before generating a frame

We could add another method, where you can use VSYnc to halve or quarter the framerate, which can have better pacing potentially.

[shiftyscales]

It is a very common solution to have in-app frame limiting. Similar to what you had mentioned on today's stream- capping the framerate lowers the resource usage for the application, which in turn results in lower power draw, and less heat generation, which is useful not just in the background, but the foreground too, @Frooxius. Some games even call this a "laptop mode" where it'll lock the framerate to say ~30 FPS.

E.g. my laptop display is 165 Hz, I could cap it to say 30 FPS which is all I'd need for general desktop Resonite use, or 60 if I were streaming/recording- which is another application for foreground frame limiting- saving resources for encoders while recording/streaming with a single PC setup.

---

It is possible to constrain it either with software like RTSS, or at the driver level, but in-app limiters are also quite useful. It is recommended to use internal/native limiters, as external limiters can add a frame or more of latency.

In-game framerate limiters, being at the game’s engine-level, are almost always free of additional latency, as they can regulate frames at the source. External framerate limiters, on the other hand, must intercept frames further down the rendering chain, which can result in delayed frame delivery and additional input latency; how much depends on the limiter and its implementation.

https://blurbusters.com/gsync/gsync101-input-lag-tests-and-settings/11

---

Likewise, with Gsync monitors, it is also recommended to cap your framerate slightly below the display's refresh rate to minimize end to end latency.

As the results show, just 2 FPS below the refresh rate is indeed still enough to avoid the G-SYNC ceiling and prevent V-SYNC-level input lag, and this number does not change, regardless of the maximum refresh rate in use.

https://blurbusters.com/gsync/gsync101-input-lag-tests-and-settings/5

This is advice than Nvidia also shares.

To maximize latency reduction in GPU bound scenarios where FPS is consistent, set Max Frame Rate to a framerate slightly below the average FPS and turn Low Latency Mode to Ultra.

https://nvidia.custhelp.com/app/answers/detail/a_id/4958/~/max-frame-rate%3A-cap-frame-rates%2C-save-power%2C-and-more

Nvidia has added functionality in their drivers to minimize end-to-end latency, but it is still useful to have in-app limiters for convenience, power savings, and lowering end-to-end latency in GPU-bound environments, as well as for users making use of Gsync VRR displays.

---

Having half/third/quarter step Vsync settings would also be welcomed additions, but are not a replacement for foreground FPS limiting, particularly as Vsync can drastically increase end-to-end latency. Framerate locking for Vsync also only applies in the context of double-buffered Vsync- triple-buffered Vsync removes that limitation at the expense of an additional frame of latency, depending on the implementation.

As for “triple buffer” V-SYNC, while the subject won’t be delved into here due to the fact that G-SYNC is based on a double buffer, the name actually encompasses two entirely separate methods; the first should be considered “alt” triple buffer V-SYNC, and is the method featured in the majority of modern games. Unlike double buffer V-SYNC, it prevents the lock to half the refresh rate when the framerate falls below it, but in turn, adds 1 frame of delay over double buffer V-SYNC when the framerate exceeds the refresh rate; if double buffer adds 2-6 frames of delay, for instance, this method would add 3-7 frames.

“True” triple buffer V-SYNC, like “alt,” prevents the lock to half the refresh rate, but unlike “alt,” can actually reduce V-SYNC latency when the framerate exceeds the refresh rate. This “true” method is rarely used, and its availability, in part, can depend on the game engine’s API (OpenGL, DirectX, etc).

A form of this “true” method is implemented by the DWM (Desktop Window Manager) for borderless and windowed mode, and by Fast Sync, both of which will be explained in more detail further on.

https://blurbusters.com/gsync/gsync101-input-lag-tests-and-settings/4

Sorry for the lengthy post- but hopefully the articles/references provided help explain what I had meant, @Frooxius.

[Frooxius]

My main issue with this is that we don't have mechanisms to use any of these things you mentioned - we can limit the framerate to a specific number, but Unity specifically advises against using this: https://docs.unity3d.com/ScriptReference/Application-targetFrameRate.html

This makes the other things (GSync and whatnot) largely irrelevant to this.

If we want to have better pacing while limiting the framerate, then we'd have to use the vSyncCount, which can only divide the native framerate.

From the sound of it you're wanting to turn this into GSync/FreeSync support? That would make this quite different and much different issue and potentially not possible until we switch graphics engine.

[shiftyscales]

@Frooxius - From the provided documentation you linked, my primary use-case/want for this feature is:

You can also reduce your game's frame rate to conserve battery life on mobile devices and avoid overheating.