I'd be interested in seeing those threads if you have links. If you want a place to vote for a feature like this, there is always the feedback site. Right. Unfortunately we can't read all threads in the forums and I guess we missed those more specific ones. Right. The problem is that with the long frames approach, you somehow have to be able to tell the back-end about what kinds of input you care about and what doesn't matter. And because we have a very minimal back-end and a lot of input translation and processing work happen in the front end only, there's no simple way to tell the back-end "you should resume on this specific input" because the input is in a different format on the back-end, and our translation logic only goes in one direction. With the skip frame approach, we wouldn't have this problem as the code that handles the input can know exactly what input is used and what isn't and skip or not skip frames based on that. For physics, you'll get the same amount of physics frames regardless of the target frame rate, so neither approach will make a difference there. For animation, skipping animation might make sense for a frame. If you could profile your games and see yourself which systems take up the most processing time, that could be helpful for informing if the skip frames approach might be viable.