The person who made that video should change the title. That monitor is not lagless, infact just about no lcd/plasma is. That video is very misleading. That evo monitor I believe has around 6-9 ms input lag, not 0. I can't remember exactly, but I remember reading about it before, it's pretty popular. So the 27 inch seems to be behind that a bit. The bigger you go, the more input lag they seem to have. I'm sure you can find a 27" with under 10ms though. Google the words ["27 inch" "input lag"] write it just like that including the quotes, but without the brackets, then repeat the same search but change "27 inch" with "27"" (one quote after the #7). Should be lots, maybe even the one you're looking at.
But wouldn't you rather just run 120fps with vsync off (regardless of wether the monitor is 60 or 120)???
I would as I'm not that sensitive to tearing... and as a bonus I would get lower input lag without vsync.
For sure, but running 120 fps on a 120hz compared to 120 fps on a 60 hz doesn't give you less input lag, it just gives you a greater resolution of frame output, a new frame gets displayed visually every 8ms or so instead of every 16, so you see more frames in between, but I'm pretty sure it won't mean less input lag. Correct me if I am wrong, but it's like a brake pedal with 512 bits of resolution and another one with 1024, the one with 1024 doesn't give you less input lag, it just gives you more steps in between for greater resolution, greater detail.
I thought this thread was captain obvious right from the get go, anyway. Here is a decent read on input lag, beware it's a bit long. There is also many more out there. Google is your friend. http://www.prad.de/en/monitore/specials/inputlag/inputlag.html
Oh I'm sorry. Automatically assumed he was comparing to a virtually lagless CRT-monitor. Also by reading PRAD's article about measuring monitor input lag (thanks CdnRacer!) it's clear the method in the video is pretty useless anyway.
I got bit puzzled by your example. First I agreed with it and it seemed like it doesn't add any lag and just gives greater resolution like you said. But by thinking it over then actually higher resolution means lower lag and here's why. Personally when I'm having trouble understanding some phenomen then I exaggerate limits and/or try to pause things and visualize "movements" in slow-motion. I've heard Einstein used to imagine a ray of light in a slow-motion when he was developing his theory of relativity. I'm no Einstein for sure but that method seems to work in many cases. Let's imagine the brake pedal example but for the sake of simplicity let's assume those polling intervals are 100 and 200 Hz. This means that 100 Hz brake controller asks new information (polling) every 10 ms and 200 Hz brake controller polls every 5 ms. At the moment of time 0 driver is just about to press the brake pedal; both 100 and 200 Hz brake controllers poll the value from brake pedal sensor and receive pedal position 0 % At 1 ms: driver starts to push the pedal. Pedal position is 1 % At 2...4 ms: Pedal position is changed from 2 to 4 % At 5 ms: 200 Hz brake controller polls pedal sensor and receives pedal position 5 % and starts braking accordingly At 6...9 ms: Pedal position is changed from 6 to 9 % At 10 ms: Both 100 and 200 Hz brake controllers poll pedal sensor and receive pedal position 10% and starts braking accordingly So yes 200 Hz has greater detail over 100 Hz but it also starts braking 5 ms earlier hence there's difference in input lags. Same goes for 60 Hz and 120 Hz monitors; input lag is reduced by 8,3 ms assuming there's no difference in processing the display signal received from graphics adapter and both displays are able to light and dim pixels equally fast. It's important to differentiate monitor's input lag from the total input lag of the whole process and also know how the refresh rate (60 vs 120 Hz) comes into play. Let's assume both 60 and 120 Hz monitors have same input lag of 3 ms (processing the signal + lighting, changing and dimming pixels). At the moment of time 0 graphics adapter sends first image to both monitors which start to process it At 1 ms: processing the signal is completed and both monitors start to draw the image At 2 ms: pixels are starting to lit At 3 ms: pixels are lit on both monitors At 4...6 ms: pixels remain lit At 7 ms: graphics adapter sends second image to both monitors but only 120 Hz monitor starts to process it At 8 ms: processing the signal is completed and 120 Hz monitor start to draw the image At 9 ms: pixels are starting to change on 120 Hz monitor At 10 ms: pixels are changed on 120 Hz monitor At 11...13 ms: pixels remain lit At 14 ms: graphics adapter sends third image to both monitors which start to process it At 15 ms: processing the signal is completed and both monitors start to draw the image At 16 ms: pixels are starting to change At 17 ms: pixels are changed on both monitors Technically it's not like graphics adapter is sending the image etc. but it's easier to imagine it that way. So once again the total input lag is smaller (8,3 ms between 60 and 120 Hz) even though both monitors have same input lag of 3 ms. With vsync I believe input lag is reduced even more than 8,3 ms because it could also affect the processing time required in the graphics adapter. But as I said before I don't have any proof of it and it's all intuition/imagination yet to be proven.
I define input lag as the time from when you give commands on your input device until you see the action of that command on the screen. If the game engine and frame rate run faster than the screen refresh rate you will have a new updated frame for every screen refresh and obviously you then will have lower input lag on a 120 Hz system. It's like comparing running 60 vs 120 fps on a 120 Hz (or 30 vs 60 fps on a 60 Hz screen). If you like numbers: Running 120 fps on a 120 HZ screen you have on average 8 ms display delay (the age of the frame buffer when shown on the display) both in vsync on or off. With a 60 Hz screen those numbers would be 16 ms with vsync on and 12 ms with vsync off.
Yes and for example at 180 FPS tearing is so small at horizontal panning that it's almost invisible. However when head mounted displays arrive with head tracking systems then it could be completely different story with vertical panning.
That article wasn't about controller input lag discussed here but rather about LCD screen response time. Edit: Maybe it's me that have been lazy reading...
Let me know when you're playing rF2 without a monitor. I'd also like to know how to do it when you're doing it.
Heh, I guess this thread was about measuring total input lag from controller to eyes and comparing results between different sync and graphic settings. I think it was very good that monitor lag got discussed too since it's one of the key elements of total input lag.
IMO by common sense the frequency has to decrease input lag, another simple method I liked to use for math problems since elementary is to start with extreme cases and then think whether the tendency towards extreme can be there. Let's imagine our monitor would only have 1Hz refresh rate. Total lag would inevitably be whole 1 second, wouldn't it? So 120Hz should make you able to react faster practically reduce input lag, not just producing nicer fluider image...
Yes but if a 60hz monitor has 7ms of tested input lag, if that monitor was magically converted to 120hz, it wouldnt all of a sudden have lost any input lag, it may be down to 6.8 on average, because the monitor is ready much quicker (double) to update the screen image u see. The refresh rate means how many times per second your image is updated to you visually, that does not change any lag. If the monitor all of a sudden had 10000000 hz refresh rate it wouldn't matter, because you are still always going to be lagging behind your inputs, once you see the movement on screen it will look more smooth as the image is getting redrawn so many times a second, but the initial delay due to the monitor having to process information, post processing and whatever work it does is still going to cause that lag, no matter if it is 60hz, 120hz or 50000000 hz. There are 3 guys waiting for me to hand them a bunch of apples, and a 5th guy who would shout "GO!" Every time he shouts "GO!" (this would be your controller input polling rate) it means that I am allowed to reach for my bag of apples and hand one apple to one of the 3 guys (this is the work that your monitor does in order to display an image). One guy can grab the apple from my hand and place it on the table 1 time every second (monitor refresh rate), the other guy can double it and place the apple from my hand 2 times every second, the last guy is a robot, he can place an apple from my hand to the table so fast, 10 times a second. Well, if it always takes me 0.5 seconds from the time of "GO!" to reach for my bag of apples, extend my arm out and pass the apple to them, then by the time the guy said "GO!" until the apple is finally gone from my hand to theirs and then on the table, they will all always be a MINIMUM 0.5 seconds behind from when the guy yelled "GO!" (your initial controller input). Now the guy who can grab the apple from my hand and place it on the table only 1 time a second, might be in the middle of his movement from the previous apple (slow refresh rate) so it would take him time to finish placing his last apple on the table while I am waiting for him to grab the next apple, so this slower refresh rate will add further time on top of the initial 0.5 seconds of lag. While the robot can place the apple from my hand to the table so fast (10 times a second) will always be ready much quicker to grab the apple from me and place it on the table, so he doesn't add that much lag on top of the 0.5 s delay because his refresh rate is so fast he is always ready for the next apple. All 3 guys will ALWAYS be at the MINIMUM 0.5 seconds behind due to my processing time (time it takes for me to grab an apple from the basket and extend my arm out from when the guy yells "GO!"), this is the image processing/working time where 99% of the lag comes from. The higher refresh rate guy, the robot in this case, will only minimize how much time gets further added to that 0.5 s delay, but he can never do anything about the first 0.5 s delay (the time it takes for the monitor to process the image). So the robot can potentially minimize how much time is added to that 0.5 s delay because he is so fast and ready for another apple so much quicker (higher refresh rate), but no matter how fast he is, he can never EVER be less than 0.5 s behind, because I always take 0.5 seconds to grab an apple from my basket and hand it to the robot (image processing time, which is where most of the lag comes from) from when the other man first yelled "GO!" (your user input). You see what I mean? This is all in my head, not saying I am 100% right haha.
Makes sense, so basically as I understand you're saying the total delay from your input is the input lag (which is constant for said monitor) PLUS the time it takes to draw one screen (aka 1/frequency). In that case considering 1Hz refresh is irrelevant because those 1000ms for redraw compared to which 7ms is neglectable. But at 60Hz it is 16.6+7ms=23.6ms, at 120Hz it is 8.3+7=15.3ms. Which would show that each ms of direct input lag makes bigger difference that 1 or 2 more Hz frequency. But I can see we are all guessing here a bit, maybe we should first read some proper material about how monitors work, frankly I know nothing about them, and then discuss facts
I would guess yes it have to, because to handle the increased bandwidth and pixelclock, the monitor has to process data faster and probably then also get a faster response time. That would maybe have been true if the image would appear instantaneously (sp?), but it doen't. The picture is drawn pixel by pixel during the whole refresh interval. While the first pixel turn up at 0 ms the last pixel will be updated in 16 ms on a 60 Hz display and after 8 ms on a 120 Hz display. That means that you will definitely have greater lag on the lower part of the display with a 60 Hz screen. The last line written on the display will NEVER be younger than 16 ms on a 60 Hz display running with vsync on.
You don't understand what I am saying. Read my example about the apples. The input lag isn't coming from the refresh rate itself, the input lag is coming from the processing and "thinking" that the monitor does BEFORE it starts to enter the "draw image on the screen" refresh phase. If you read my apples example, you will see that the refresh rate can only minimize the lag from the time when the monitor starts to output the image. The thing is, that is not where the problem is, the problem comes BEFORE that, before the monitor outputs the image, it is doing all this other processing and "thinking" work, this comes before the "image gets drawn on the screen" phase, that is why the refresh rate has almost no effect on the input lag, because the lag is coming from a completely different step of the process BEFORE refresh has any affect, because it has not gone onto the "draw image on screen" phase yet. This is, I believe, why some of the lowest input lag monitors tested are still only 60hz, because the lag is coming from additional processing and overhead that happens before it even reaches the "draw image on screen" refresh phase, so therefore the refresh rate has almost no say on the matter because at that point it's already too late.
Ah I understood it completely wrong then, go be honest I didnt read your post much only glanced through it because I thought you're only describing that it's that measured lag + time to draw but this is obviously completely wrong (I said I know nothing at all about monitors). If it's the way you say then 60Hz can actually be better for gaming - or not, depends on whether a person is more sensitive to mere fluidness of the picture or to the lag.?
