Turn on frame generation and your overlay jumps from 60 to 120. Objectively better, by the one number everyone uses to judge performance.
Now move the mouse. The game responds exactly as it did at 60, and in most implementations slightly worse.
That gap between what the counter reports and what your hands experience is the whole story, and it is worth understanding properly because the technology is genuinely useful in the places it fits and genuinely counterproductive everywhere else.
Why the Extra Frames Contain No Information
A rendered frame is the engine’s answer to a question: given the state of the world and your inputs right now, what should the screen show?
A generated frame asks nothing. It is interpolated between two real frames, which means it contains no new input sampling, no new world state and no new information of any kind. It is a plausible picture of a moment nobody simulated.
Which is fine for your eyes and useless for your hands. Motion looks smoother because more images arrive per second. Responsiveness does not improve because the engine is still sampling your mouse at the original rate.
At 60 fps native with 2x generation, the counter reads 120 and displayed frame time halves to 8.3ms. Input is still being read every 16.7ms, exactly as before.
It Actively Adds Latency
This is the part that surprises people, and it follows from how interpolation has to work.
To generate a frame between two real ones, you need both real frames first. Which means the second one has to be rendered and then held back while the interpolated frame is inserted ahead of it.
You are deliberately delaying a frame you had already finished, in order to show a made-up one before it. At 60 fps native that costs up to a full frame interval, so roughly 16.7ms of additional latency on top of whatever the pipeline already carried.
Latency reduction features exist to claw some of that back, and they do help. They do not make the technique latency-neutral, and anyone telling you 120 generated frames feels like 120 native frames has not measured it.
The Published Number and the Real One
Which puts frame generation in a familiar category: a specification that is technically accurate and describes something other than what the buyer cares about.
Monitor response times are quoted under overdrive settings that introduce overshoot artefacts. PSU wattage figures describe peak rather than sustained delivery. Storage sequential read speeds have almost nothing to do with game load times.
In every case the number is not false. It simply measures a property that is easy to maximise rather than the property that determines your experience, and the gap between the two is where marketing lives.
Ranked comparisons across any technical category run into the same problem, which is why the useful ones state their methodology rather than only their conclusions.
Online casino rankings are a decent illustration from an entirely different sector. A casino comparison built around payout speed produces a different order from one built around game library size or bonus terms, and neither ordering is wrong. What makes a casino list checkable is whether it says which criteria it weighted, exactly as a benchmark is only useful once you know whether the figure came from native rendering or from generated frames.
Texas online casinos ranked by Metrotimes is a reasonable example of the format, where the ordering depends on stated criteria rather than arriving as a bare verdict. The principle transfers directly: a number without its methodology is a claim, not a measurement.
A frame counter is a ranking with one criterion. It was never designed to answer the question people use it to answer.
Where It Genuinely Works
None of which makes the feature bad. It makes it specific.
Single-player games with high base frame rates. Starting from 60 or above and generating upward is where it shines. The added latency is small relative to a comfortable baseline and the smoothness gain is real.
Slow-paced titles. Strategy games, builders, walking sims, anything where a 16ms delay is imperceptible because nothing requires a reaction.
High refresh displays that would otherwise go unused. A 240Hz panel fed 80 native frames is mostly idle. Generation fills it, and the motion clarity improvement on a fast panel is genuinely visible.
Where it fails is the inverse. Competitive shooters, fighting games, anything where input latency is the performance metric. And critically, using it to rescue a low base frame rate, which is exactly what most people reach for it to do.
The 40 FPS Trap
Worth naming directly, because it is the most common misuse.
Running at 40 fps, you turn on generation, the counter reads 80 and the game looks smoother. Your input is still being sampled every 25ms, plus the interpolation delay on top.
So you now have a game that looks like 80 and controls worse than the 40 you started with. The visual improvement is real and the thing that was actually making it feel bad has got worse.
Dropping a setting or two to reach 60 native would produce a better experience than generating from 40, every time, and it is the less appealing option because the counter goes up less.
What to Measure Instead
Three things, in order of how much they affect how a game actually feels.
Native frame rate before any generation. This is your real performance figure and the one that determines responsiveness. Everything else is presentation.
End-to-end system latency. Tools exist to measure click-to-photon properly, and documentation on latency pipelines explains where the milliseconds actually accumulate. It is rarely where people assume.
1% lows on the native figure. Generation smooths the visual appearance of a stutter without fixing the stutter, which means a spiky native experience can look fine and still feel wrong.
Judge the feature on what it was built for and it is a good one. Judge it on the counter and you will keep making the same trade in the wrong direction. More testing and component analysis across our hardware reviews.
