Blur Busters Forums

Hi gang,

If anyone hasn't already seen it, there is an excellent review on TFTCentral covering the new Asus MG279Q 144hz, IPS, FreeSync, 1440p monitor:

http://www.tftcentral.co.uk/reviews/asus_mg279q.htm

Out of tearing, motion blur and input lag, the latter is my number one pet hate and I find anything > 10ms intolerable (and much prefer things being around the 5ms or less mark).

One of the disappointments for me in this review is the measured input lag when using the Freesync mode (which is capped at 90hz) and gets a result of 13.35ms.

The great news, however, using 144hz mode, the input lag is only 4.05ms - perfect.

This has got me thinking, however, what is the relationship between input lag vs. refresh vs. framerate?

To clarify this, what I mean by this is the following questions is if my refresh rate is set to 144hz but I'm only achieving around 60fps, I know I will suffer tearing but will my input lag remain at 4.05ms or am I going to see input lag figures around the 13.35ms+ mark as was the case with 90hz (i.e. do I need to be hitting 144fps consistently to get 4.05ms of input lag)?

Oh no. Is this another area where Adaptive-Sync is deficient compared to G-Sync's solution of having an FPGA inside the display to handle the processing?

This has got me thinking, however, what is the relationship between input lag vs. refresh vs. framerate?

With v-sync off, framerate inversely correlates with how old the newest line on the monitor is, and refresh rate determines how long that line stays on screen before it can be replaced with a newer line.

The location of your framerate bottleneck has a huge impact on latency as well. CPU bottleneck is better than GPU bottleneck, and GPU bottleneck is MUCH better than a v-sync display bottleneck. If you're using VRR, you should cap framerate within the VRR window. Basically, the single slowest part of the render chain spends 1/framerate on each frame, and every step BEFORE that also takes 1/framerate because they're waiting on the bottleneck to clear before they can send their frame to the next step of the pipeline. Every step after the bottleneck would only take the actual calculation time. If you have a bottleneck at the front, like an in-game framerate cap, you get minimal latency.

relevant image i made last year


as for refresh rate, it basically adds another random variable that's roughly uniformly distributed between 0 and 1/refresh rate

well depending on whether only part of the screen changes in response to input or the whole screen changes.


@topic: welp looks like the acer xb270hu wins