How to decouple rendering from tick rate?

[rowanfr]

After having looked around for a bit I can't seem to find an answer to this. The only reference to this that hits the nail on the head as to what I'm looking for is @alice-i-cecile's comment from 2021: System control flow patterns
To restate the section I'm interested in here:

Fixed timestep, decoupled rendering ... Much of the game loop (typically physics) only advances when a certain fixed amount of time has passed. Note that this control flow pattern and the hybrid turn-based pattern above can be unified into a decoupled game loop control flow, where the criteria differs.

What I'm trying to do is look for some way to decouple rendering from the game tick rate and then after set the tick rate and render refresh rate (though presumable refresh rate would be uncapped or matched to the monitor). How would I be able to do this or has such a feature been implemented yet?

[nicopap]

You might be interested in fixed_timesteps. (example here). It has some caveats I'm not too familiar with.

If you want however to control the update rate of rendering (for example only render frames when certain events occur), you need to look at winit settings, see usage at this example

[rowanfr]

This mostly answers the question. Winit settings seem to control render rate depending on if it's in the main view or interacting with OS features which determines if the program can go to a lower power consuming stage, but window::PresentMode seems to focus more on frame rate presented to the window. It's not precisely controlled similar to fixed timesteps but it doesn't really need to be so long as it can either have an uncapped frame rate or vsync. (To be clear I haven't tested this yet because I can really visually tell different frame rates so I need to set up a live frame counter, I will update the comment when I do).

I've been doing some testing with the fixed timesteps and they lead to more questions that I will put in a separate discussion thread. The main issue is that keyboard input events seem to be able to avoid registering if the inputs are made outside of the timestep. I can resolve this by decreasing the timestep or having a separate faster polling system but I presume that the events being misread isn't expected as that would undermine their purpose relative to reading the input resource so I'm trying to understand why it happens or if my understanding of how bevy handles inputs is fundamentally wrong.