[fergal_reid]

Is this actually true, or BS? If true, can someone explain?

My mental model is that vsync will lock the framerate to the same as the monitor refresh.

So if monitor is 60hz, my games graphical update rate runs at 60fps.

Let's say without vsync, my graphical update rate would generously go up to 120hz.

Worst case we're talking about an additional input latency due to vsync of maybe 1/60s? 16ms?

I don't believe 16ms is significant for non pro level eSports players and even skeptical it's a big factor at that level.

What am I missing here?

I could understand if the get clock speed was tied to the graphical update rate but I presume that's not the case for CS, server side game etc; or even if it was it's still not going to be that material.

I'm just skeptical - what am I missing here?

Is the mouse input code tied to graphical clock rate or something in some surprising bad way?

[enragedcacti]

>Worst case we're talking about an additional input latency due to vsync of maybe 1/60s? 16ms?

its generally closer to 2 frames with V-Sync [1][2]

> I don't believe 16ms is significant for non pro level eSports players and even skeptical it's a big factor at that level.

It actually is fairly significant. LTT did a series of tests with pro players in CS:GO focused on monitor refresh rate, but one test they did was 60hz/60fps vs 60hz/300fps and found that reducing the render latency drastically improved performance despite the display still being locked to 60hz.

https://youtu.be/OX31kZbAXsA?t=1911

[1] https://displaylag.com/reduce-input-lag-in-pc-games-the-defi...

[2] https://www.cse.wustl.edu/~jain/cse567-15/ftp/vsync/index.ht...

[dbttdft]

uggh.

> [1]

They got Freesync having less lag than no synchronization which means their measurements are likely wrong.

> [2]

All the lag can be calculated on paper, why do they need an empirical study? Their definition of triple buffering is one of following: One is FIFO, used by Microsoft, which causes even more lag than just double buffered. The other is some obscure mode I barely even remember that is incorrect because it drops or doubles various frames.

[dbttdft]

It impacts even casual game play.

Run a monitor at 60Hz. Run whatever FPS locker you want (whatever the game has built in, RTSS, etc) at 60FPS then run with the frame locker removed but vsync on. The average person will notice the huge difference. It will be impossible to aim on the latter without getting used to it, and even then you'll still miss lots of shots that you know you should have hit.

[leetcrew]

it's true that all of these things make a pretty noticeable difference when you know what to look for. but you're not going to recognize 60hz or vsync as "unplayable" unless you're very accustomed to playing on a better setup.

> I could understand if the get clock speed was tied to the graphical update rate but I presume that's not the case for CS, server side game etc; or even if it was it's still not going to be that material.

in cs source, the client could not send updates to the server at a faster rate than it was drawing frames. in other words, if you were playing on a 66 tickrate server but only rendering 50 FPS, you were actually losing some simulation fidelity. of course, if you're not the type of person to notice your frame rate dropping to 50 in the first place, you would probably also not notice this consequence. just an interesting technical fact.

[dbttdft]

60Hz vsync literally feels worse than 50FPS/60Hz uncapped. I believe 32ms of input lag is not in itself blatantly noticeable. But on top of the base lag of every single game made after 1998, it's extremely bad.

[hackerman_fi]

The vsync latency is real and unbearable in some games. I think it uses a queue/buffer for frames which can cause latencies of multiple frames.

[r9550684]

if you have 0 input delay, worst case latency is still 32ms, because your input might come in when back frame is ready, but blit hasn't happened yet: render frame A, input comes in, blit frame A, render frame B, blit frame B.

but your input delay is not 0, so your input might come in before frame A above, but frame A doesn't reflect input yet, which makes your worst case input latency 48ms: input comes in, blit ..., render frame A, blit frame A, render frame B, blit frame B.

there are also bad vsync implementations, that by virtue of being enabled, introduce further delay between state and graphics. or if fps drops under refresh rate, things go out of sync, and your vsync becomes a compounding effect.

finally vsync delay existing in addition to whatever other delays. a 30ms delay for whatever reasons, becomes an 80ms delay because vsync on top.

[dbttdft]

Here's how I see it:

99% of the time a game after 1998 or so says "vsync" it means double buffered vsync, so I'll explain that version.

Let's say the game renders frames instantly.

Without vsync but locked at 60FPS, an input can take up to 16ms to cause an effect on the monitor because the game loop only applies and renders pending inputs once every 16ms at this framerate. Each input will have between 0ms and 16ms of lag.

In double buffered vsync at 60Hz, its the same thing: the game loop applies and renders pending inputs once every 16ms. But now the frame is not shown on the monitor right away. Instead, the loop waits for the monitor to be ready. And because the loop will restart right after that, this wait will always be another 16ms. Each input will have between 16ms and 32ms lag.

Of course if your render takes more than 16ms you will have more issues, but that's not the problem here. Even with a computer that renders instantly, the lag will be too much.

And yes this will be on top of the already existing lag of the game and peripherals.

I don't understand how you get 48ms. If I have a mouse with 4ms of lag, it will just add a constant 4ms to the total making worst case 32ms + 4ms. I did think it was 48ms at some point but now I think I just imagined it.

[r9550684]

you're right, I fucked it up with 48ms logic. an input lag will go to a second 16ms cycle instead of the first one, rather than somehow magically creating a third one