Arulan wrote:I've heard mixed opinions on using a frame limiter with Vsync. Some believe it will always either reduce input latency at the cost of frame time consistency or do nothing. In my experience, if you were to set it below 60, you would reduce input latency at the cost of frame time consistency, but at exactly 60 it reduces input latency a little (not as much as before) while maintaining perfect frame time consistency.
It depends on the engine hugely too.
In the situation of extremely fast GPU's (e.g. Titan/980/10X0 cards on Source Engine), your frame times are going to be tiny, e.g. 2 millisecond per frame. This makes Source Engine type games very friendly to latency-reduction via a good frame-capping utility that correctly waits a certain amount until a last-minute input read before rendering before VSYNC.
This works well when you're using older engines whose minimum (slowest framerates) are still extremely high (e.g. framerate fluctuate 300fps-1000fps) which means you can still have perfect motion fluidity because the frametime variability is far less than 1 refresh cycle... aka having your cake and eating it too. The problem is few games will have minimum (slowdown) framerates in the stratosphere like that, like you'd get with a Titan/GTX980/GTX1080 on Counter Strike:GO -- a game that is still very popular in eSports today -- it permits you to have virtually perfect-motion (zero microstutter) VSYNC ON while simultaneously having far less less input lag, with the correct kind of frame capping. The problem is, "what kind of frame capping should I use". Sometimes it's just easier to simply use fps_max, rather than tweaking with more complex framerate limiters...
With the right frame capping utility, in theory you can delay rendering a frame until a few milliseconds before thge next refresh cycle. Say, easily 3-4ms before the next refresh cycle. At this stage, whether frametime varies 0.1ms-3.9ms doesn't really matter, as long as input reads occur exactly 3-4ms before VSYNC page flip, because you're going to finish rendering the frame very quickly anyway.
If you've got enough overkill where FRAPS show variability inside a tighter 2ms range, you could even reduce that to just 2ms before next refresh cycle! (GTX1080 on older Source games). In theory, you want perfect input lag consistency (<1ms variability) for very good VSYNC ON, perfect jitter-free lag & perfect microstutter-free motion, as long as your frametimes vary in a range of 0ms-2ms. Say, you do input read say, exactly 2ms before VSYNC, use overkill GPU to render the frame fast (~1ms), then flip quickly at VSYNC. Now you've got VSYNC ON that has 14.7ms less lag (~16.7ms minus 2ms at 60Hz) or 6.3ms less input lag (~8.3ms minus 2ms at 120Hz) than the most crude/simplistic kind of double-buffered VSYNC ON where input reads & rendering occurs immediately after the page flip -- this is all too common in many games. This would make, in theory, an eSports-friendly VSYNC ON, very useful with blur reduction strobe backlights (usually not eSports friendly).
You just add enough safety margin to allow frametime inconsistency (of complex scenes) to be finished before VSYNC.
On the fastest cards (1080) running Counter Strike:GO, you can hit many situations of sub-1ms frametimes, so you can easily reduce your VSYNC ON lag by ~75% with the right kind of frame capping utility. This can be excellent for people who prefer using Blur Reduction (which looks better with refreshrate-framerate matched motion)
For many games, you will never be able to get FRAPS variabilities to a tiny fraction of a refresh cycle so you won't be able to do this trick in a microstutter-free perfect-non-varying-latency way. But we're already approaching the era where there are still popular older (e.g. CS:GO) games running on overkill GPUs (e.g. GTX1080) where it is becoming theoretically possible to just use a fixed delayed input read & render, while getting perfect results (zero varying lag + zero microstuter + low lag VSYNC ON) in a "have cake and eat it too" effect. For this to happen very easily, FRAPS need to show tight rendertime bands, such as, say only 25% (or less) of the time of a refresh cycle (in milliseconds). More testing will be needed to find the right kind of games & right kind of framerate limiter to achieve this "have-cake-and-eat-it-too" low-lag VSYNC ON effect in certain games, but mathematically it appears to be possible at least for some older engines.
For specific games that executes input reads immediately after a VSYNC ON page flip, there is one possible sledgehammer method (possibly already exist in one of the frame rate limiters) -- basically a "crude framerate limiter" scenario is a theoretical intentional ultra-precise busywait (using raised process priority) of exactly ~X.Xms right after a VSYNC ON pageflip, before letting CPU get back to the game engine. This reduces CPU available to the game engine, but this doesn't matter for older game engines. But it would suddenly stablize FRAPS numbers into a very tight frame variance band (possibly <1ms jitter). This might be the magic piece necessary to force Source Engine games to have up to ~6ms input lag (3/4ths of a refresh cycle less) during VSYNC ON at 120Hz (8.3ms refresh cycles) while having perfect motion (no microstutters) and near-perfect lag consistency. Some testing will be needed. In this theoretical frame rate capping technique. you're robbing CPU time away from the game (an older engine, mind you), but in exchange for running a steamroller on top of the FRAPS graph (as a result, making motion even more perfect-looking during VSYNC ON, and making input lag almost perfectly flat) in this theoretical crude frame capping scenario. You'd want a very precise busywait loop though. I wonder if there's any frame capping software that can insert an intentional ultra-precise busywait after a VSYNC flip, to test this lag-reducing theory (forced precise-delayed input read trick). You'd also want to turn off multicore rendering in the source engine game, and it'd have to be a game that does an input read immediately after returning from a VSYNC ON page flip.
More testing is needed by all those of you who have the equipment to do so -- but reducing VSYNC ON input lag by 3/4ths of a refresh cycle would be huge deal for many people who prefer VSYNC ON (if it was just a "little better")