Does having 60FPS using VRR have lower input lag than 60hz? Confused*

[jorimt]

Then rephrase it to be then clear about context. Wink. (You know me by now, ha!)

I specifically said "a bit" of a misnomer, not "a misnomer." I found that clear enough with what had preceded it and followed it in this particular thread.

This actually would make stutters worse.
Consistent scanouts is required to keep gametime:photontime time-relativity consistent.

I merely meant if VRR could theoretically control both repetition and completion time of the scanout, completion time could potentially be fractional as well. Whether that is practically applicable and improves anything is another question, especially once the game is thrown into the mix. This goes for your rebuttal to my LFC comment as well.

My main point was VRR does not control both.

Further confused discussion on this may create a large Blur Busters Article that explains the physics. Y'all be warned.

Go for it. More BB content is always a good thing

[Chief Blur Buster]

I merely meant if VRR could theoretically control both repetition and completion time of the scanout, completion time could potentially be fractional as well. Whether that is practically applicable and improves anything is another question, especially once the game is thrown into the mix. This goes for your rebuttal to my LFC comment as well.

Not possible.

LFC mismatch only exists because refreshing is a finite-time endeavour that can have a schedule-conflict with a video game suddenly unexpectedly ready to deliver a new refresh cycle (at an unexpected time to the LFC algorithm).

Game's finished rendering a frame, now it's waiting for the monitor to finish refreshing its earlier repeat-refresh cycle.

LFC is inherently a predictive manoever by necessity; monitor doesn't know when the the game engine will deliver its next frame.

Also, back to screen refreshing patterns. For a goal of clean motion, screens have to refresh in entirety in the same refresh pattern, at the same velocity, every refresh cycle for consistency (to avoid artifacts, stutter, tearing, combing, zigzag-edge artifact, strange variable bending/warpinging far worse than www.testufo.com/scanskew on a 60Hz DELL/HP office monitor / etc.) Random-access pixel refresh and variable-order refreshing have visible artifacts unless done at ultrahigh frequencies (like far beyond DLP pixel refresh speeds, 1440Hz/1920Hz).

By scientific principles

1. Refreshing is a finite-time endeavour
2. Screens have to refresh in entirety in the same refresh pattern, at the same velocity, every refresh cycle for consistency
3. There is a minimum refresh rate before panels glitch
4. LFC is the monitor deciding to do a repeat-refresh cycle because a new refresh cycle (new frame) hasn't arrived yet
5. LFC mismatch is when new frame arrives earlier than expected
6. Games don't always have consistent frametimes
7. The device doing LFC (Monitors/Drivers) generally can't read the mind of a game

Connecting the dots, LFC succeeds when framerates are consitent, because LFC can just time the repeat-refresh half a refreshtime later (based on refreshtime history).

But given a random framerate game with erratic frametime -- you can have frames thrown at the monitor unexpectedly soon -- then the monitor may be busy refreshing. The frame now has to wait before the repeat-refresh finishes. So now you've injected gametime:photontime inconsistency = aka LFC stutter.

[Chief Blur Buster]

Now -- one possible out: In theory, interruptible repeat-refreshing could be invented, since repeat-refresh is in theory a no-operation.

Good idea, in theory. If only screen technologies were perfect enough...

Stop the repeat-refresh on the spot and begin anew at the scanout at the top.

The problem is the LCD molecules are always in perpetual motion and GtG varies by refresh rate.

The repeat-refresh has behaviors that equalizes the GtG of all pixels (a repeat-refresh helps bumps the GtG a bit, so repeat-refreshed 60fps@120Hz has different GtG than 60fps@60Hz or 120fps@120Hz.

Tests in interruptible repeat-refresh creates artifacts like extra fade/dimming/ghosting on bottom half that looks slightly worse than a tearing artifact -- like a tearing-flicker effect.

Even OLED has issues given the variable effects of OLEDs during VRR (like variable gamma), so you don't want bottom half to have a different gamma than the upper half (a gamma-tearing artifact caused by an interrupted repeat-refresh).

The current preferred pick-poison is stick to consistent (same refresh pattern/velocity/completeness for ALL refreshes), and let a stutter happen for that specific refresh cycle.

[jorimt]

Now -- one possible out: In theory, interruptible repeat-refreshing could be invented, since repeat-refresh is in theory a no-operation.

Good idea, in theory. If only screen technologies were perfect enough...

Stop the repeat-refresh on the spot and begin anew at the scanout at the top.

You saved me the trouble of finishing my in-progress reply.

This is pretty much exactly what I was trying to suggest. Again, I only posed it as a theory. I wasn't suggesting (and wasn't even sure if) it was actually practical. It sounds like there would certainly be some gotchas and trade-offs involved.

[Chief Blur Buster]

You saved me the trouble of finishing my in-progress reply.

This is pretty much exactly what I was trying to suggest. Again, I only posed it as a theory. I wasn't suggesting (and wasn't even sure if) it was actually practical. It sounds like there would certainly be some gotchas and trade-offs involved.

Oh, then that's what you meant. Well, good suggestion!
Unfortunately, I have heard from multiple channels they've tried that trick and panels are too imperfect to make it the lesser of pick-poison.

Fortunately, LFC stutter falls below the noise floor for ultrawide VRR ranges like the 360Hz ASUS whose refresh rate range is ginormous.

LFC at 20fps for a 50ms frametime, with a 1/360sec scanout, is only 2.8 milliseconds delay to a 50ms frametime. That stutter is generally completely hidden in the motionblur of low framerates. All repeat-refresh mispredicts on a 360Hz monitor (in casual random tests) have shown them to be invisible thanks to the ginormous VRR range (low Hz versus ultrafast scanout).

Even 1000Hz mouse microstutter is starging to be more visible than a LFC mispredict on a monitors whose VRR range is ginormously wide (approaching 10:1 max:min Hz). LFC ceases to be poison at that stage.

One can prefer native VRR range behavior to be closer to 70Hz-360Hz, since 30fps@60Hz has cleaner GtG behaviours than 30fps@30Hz and less GtG-derived faint flicker at sudden framerate changes (like bringing up a menu and disappearing it). And you avoid low-frequency inversion artifacts if there are any temporally occuring (faint shallow-cycle flickering inversion artifacts disappearing above flicker fusion threshold because of a higher minimum Hz).

When LFC ceases to be poison, it's favourable to raise LFC limit higher to erase other poisons.

[jorimt]

Oh, then that's what you meant. Well, good suggestion!

Yes. I was initially misattributing its application to the wrong aspect in my description, as I am, after all, a conceptual-thinking enthusiast, not a display engineer.

Unfortunately, I have heard from multiple channels they've tried that trick and panels are too imperfect to make it the lesser of pick-poison.

No matter. The industry is rapidly reaching refresh rates that will make syncing methods all but obsolete (even to a lesser degree where 360Hz is now concerned), so it's certainly not pressing.

[nursejoy]

What confuses me is that if I play a 60FPS game wouldn't it just bring my refresh rate down to 60hz and I would have the highest input lag i.e 12.7ms instead of the lower input lag 3.1ms because now its Variable Refresh rate @ 60hz?

Assuming RTINGS is testing and describing this correctly, If you have your max physical refresh rate set to 240Hz, you would get their reported 3.1ms input lag in VRR mode. If however you set your max physical refresh rate to 60Hz, you would get their reported 12.7ms of input lag in VRR mode.

The currently set physical refresh rate dictates how fast frames will scan in, not the framerate. In other words, 60 FPS VRR at 240Hz will always have lower input lag than 60 FPS VRR at 60Hz, as the physical scanout speed of the panel is increased regardless of current framerate.

I agree the way RTINGs describes these results can be confusing.

So I just received the monitor today. Right away I was blown away at how much better the screen quality was compared to the my old monitor the Asus XG248Q; however when doing my own input lag tests using my Time Sleuth lag tester I got these results
XG248:
top: 3.82
Middle: 11.10
Bottom 18.04
While the Alienware AW2521HF got:
Top:6.86
Middle: 11.69
Bottom: 16.65 I know obviously my numbers are different from rtings for obvious reasons like testing methodology and such but I wanted to know if the differences between the aw2521hf and the xg248q are big enough to make any difference in anything *its mostly the top (asus has lower) and bottom(Alienware is lower) that have a noticeable change in numbers*
I play a lot of consoles
I also quote replied you instead of making a new tweet because I feel I would be spamming plus you seem knowledgeable+active enough to know the answer so sorry if this bothers you in any way.

[jorimt]

So I just received the monitor today. Right away I was blown away at how much better the screen quality was compared to the my old monitor the Asus XG248Q; however when doing my own input lag tests using my Time Sleuth lag tester I got these results

Before you go any further, you need to confirm what max Hz the Time Sleuth can test at. If it's 60Hz, then the middle reading is in the ballpark of RTING's 60Hz results (9.7ms vs. 11.7ms), barring methodology differences, of course.

Chief, are you familiar with the Time Sleuth and it's differences with RTING's device? I'm assuming the Time Sleuth isn't quite as capable, specifically where higher refresh rates and resolutions are concerned.

[nursejoy]

So I just received the monitor today. Right away I was blown away at how much better the screen quality was compared to the my old monitor the Asus XG248Q; however when doing my own input lag tests using my Time Sleuth lag tester I got these results

Before you go any further, you need to confirm what max Hz the Time Sleuth can test at. If it's 60Hz, then the middle reading is in the ballpark of RTING's 60Hz results (9.7ms vs. 11.7ms), barring methodology differences, of course.

Chief, are you familiar with the Time Sleuth and it's differences with RTING's device? I'm assuming the Time Sleuth isn't quite as capable, specifically where higher refresh rates and resolutions are concerned.

The Time Sleuth is only 60hz. I know the differences are that RTINGs' devices tests are more indepth, support VRR and require a computer to run. Images are fed through usb and results are fed through that arduino? That's all I know tbh

the thing is I'm not asking if its strange my results are different than Rtings I know why it's different. I wanted to know if the top and bottom results for input lag matter much or even just a little b/c both monitors have an advantage in one of those aspects

[jorimt]

the thing is I'm not asking if its strange my results are different than Rtings I know why it's different. I wanted to know if the top and bottom results for input lag matter much or even just a little b/c both monitors have an advantage in one of those aspects

The difference you're seeing between the two models probably has to do with how each handle the scanout rate conversion at lower than 240Hz refresh rates.

If your device was capable of measuring at 240Hz, it probably wouldn't show as much of a difference between them.