The problem with vsync is that if your FPS drops below the refresh rate, the next frame is skipped, straight out halving your FPS. So if you have a 60hz display, and you're capable of rendering at 59fps smoothly, you actually end up rendering at 30fps.

Worse, if you're alternating between 55-65fps due to subtle changes in scene complexity, the FPS will flip between 30fps and 60fps erratically, which is absolutely horrific (worse than just sticking at 30fps).

To get smooth vsync 60fps, you probably want to be capable of running at 100fps on average, so there's a margin of safety and your worst case doesn't drop below 60fps.

If this technology can make 55-65fps rendering seem as smooth as a 100fps capable machine with vsync enabled, it just nearly halved the system requirements.

If it sounds like a mundane way to progress, that's because it is. All this is doing is replacing a system of bad design due to legacy reasons. Pushing data when it's done is almost always more sensible than an awkward fixed interval polling loop.

>I understand that, but if you have vsync there is already no tearing, and with a 144Hz refresh rate your lag is at most 1/144th of a second, or 7ms, and on average 3.5ms - I don't think that's something noticeable.

If the game never drops below 144 then it's not going to be very noticeable, still get extra performance of having vsync off and lower latency though. Even if you could run something that fast, though, it would likely be better overall if you could run it slightly less fast but with higher quality lighting model enabled or whatnot.

And so another way of looking at is: this lets you run at high quality than before, resulting in lower framerates of 30 - 60, because the negative effect of those lower frame rates between 30 and 60 is so minimized.