Na doesn't really matter, I guess 120 theoretically has the potential to be a tiny, tiny bit better in that regard, but again, either or will barely make a difference as it's too late by then. My current 60hz Samsung PX2370 has an average of 3.3 ms of input lag, which, other than a certain model ilyama monitor from a couple years ago (which are impossible to find in north america) is the lowest input lag I have ever seen of any monitor without going smaller than 23" (I have seen some 20-22" with even less than 3!!). I hope one day a 120hz one comes out with that little lag, the fluidity is sooooo much more beautiful and easy on the eyes. Yes, from a few posts back, you have to make sure the review site tests them a "proper" way.
Sorry to say I think it is you that are not reading my posts because your apple stories have nothing to do with how monitors work. Ok I repeat again this time a bit longer and a little more detailed. Let's start from the beginning on how the image is drawn on a display. But first, there is no image processing time. The monitor does not receive a complete image, do processing and then display the image. And most importantly there are no apples involved during the update of the display. The graphics card sends the image pixel by pixel to the monitor in an continous stream. The graphics card start sending pixel data for the topmost line first and then go downwards until the last line of the display, line by line. The monitor updates the display pixel by pixel as it receives them from the graphics card, one by one. For a complete display image with millions of pixels running at 60 Hz refresh rate all this takes 16.7 ms of continuous data transfer. No pauses, all data is streamed continuously. As soon as the last pixel of the last line of a frame is transferred the graphics cards starts all over again with the next frame sending pixel data for the first pixel on the first line. As you see there is no send image, do processing, display image. All is done in a flow and the picture is always changing somewhere on the display. A pixel can only be updated once every 16 ms but every ms thousands of pixels are updated on the display. All this happens starting from the top of the display and going downwards, then repeating when the bottom is reached, in an never ending sequence. Moving on to lag calculations. The above give us that the very first pixel on the very first line can be displayed directly 0 ms after a frame is completely created. However, the very last line of pixels will be 16 ms old when updated on the display. When we come around again to write a next frame the first pixel on the display will be 16 ms old, the time since the last update. When updating the very last pixel on the display it will be 33 ms old, the time from when the frame was created. Quoting my previous numbers above, on average the pixel shown on the screen will be 16 ms old. If running twice the refresh rate 120 Hz you see that the pixel age will be half that. In other words there will be 8 ms less lag. So what is response time or signal input lag? When the monitor receives pixel data for a specific pixel on the display it has to process the data and update the color of the liquid crystal of the display. The time it takes to do the pixel processing and get the display crystal to react to the new color data is the response time. It is measured from when the display is given a signal to a specific pixel to when the pixel crystal emits the new color. The response time is in the range of up to a few ms. (On a TV display the response time doesn't matter as you don't interact with it and the lag can be whatever and you will never notice it anyway. This will allow all sorts of processing done before drawing the pixels. This processing step can usually be disabled when you connect a computer/console to it.) The total display lag is the delay due to both the refresh rate and the response time of the display. Nowdays the response time is the minor part of that delay. Correct.
Thanks Novis for explaining the drawing process. I was also about to say the apple analogy was good but unfortunately doesn't match with the way frames are drawn on to screen. By the way do you have opinion about the reduced input lag between 60 and 120 Hz monitors when vsync is used? I mean could it lower the lag even more than 8,3 ms because processing time of vsync at graphics adapter could possibly also decrease?
You're welcome. Sorry to maybe have put your thread on a side route. The 8.3 ms less lag was calculated with vsync on and 120 fps. However the refresh delay at 120 fps would be the same with vsync off. Running with vsync on the average refresh delay would be the refresh_interval. With vsync off it would be refresh_interval / 2 + frame_time / 2, where frame time is 1 / fps. So running with vsync off would help a 60 Hz display more than a 120 Hz. But as we can see from the above formulas you could have a game that runs in the thousands of fps on a 60 Hz display, but it will never give the same low refresh delay as running 120 fps on a 120 Hz display. Finally, I would never recommend using vsync with a game that focus its gameplay on the lower half of the screen as a racing game do. Running with vsync off will on average immediately remove half the refresh time of delay on the lower half of the screen. Edit: One more example. If running sub-optimal frame rate on the 120 Hz display, say 60 fps. It will have 12 ms refresh delay compared to 16 ms on the 60 Hz so even here you have an advantage.
Novis, you are (like many) completely confusing pixel response time with input lag. This has NOTHING to do with pixel response times. They are 2 completely different things that have nothing to do with each other. I highly suggest you first research what input lag even is, as it has nothing to do with pixel response time in any way shape or form. I would have thought by 2013 people would have finally known this, I guess not.
I am no display expert so I wait with eager for you to tell me how it works. Pleaase tell me the difference.
Well I didn't have time to wait for an answer so I googled it myself. The input lag on displays is what I named response time or signal input lag. Response time seems to be the time for a liquid crystal to go through a black-to-white-to-black sequence. High response time gives blury pictures and ghosting. Thank you, I learned something new today. I can fix that in my post. Anything else?
I think too those are completely different things. However pixel response time is causing delay and is part of the total input lag from controller to eyes. Therefore, in my mind, I don't separate it from other input lags. For simplicity I like to think monitor's total input lag is the sum of delay caused by processing the signal from graphics adapter and delay caused by pixel response time.
Keikei, did you run any test with the video settings so you got 60 fps, both with vsync on and off? Number 4 and 13 seems to be closest what I searching for but isn't exactly. What I looking for here is to see if you got rid of the extra 8 ms of lag when running without vsync. But as both are within 16 ms it seems correct. Can you detect tearing lines with the cam when running without vsync? If you can then you should be able to see that the lag is 16 ms less (at 60 fps otherwise 1 / fps) precisely under the tearing line than above. How many pre-rendered frames are there on runs 1-10? One frame should give you the minimum lag.
I think what Spinelli is getting at is the processing time for any part of a signal going to the monitor before it is even sent to the screen. There are no LCD or Plasma screens that don't require the signal to be processed before it even gets to the pixels on the screen. On CRT monitors, there was no processing, the signal went straight to the color guns in the picture tube to be displayed on the screen. That being said, the amount of time the monitor or TV uses to process the signal data before it gets to the display is going to equate to input lag + the pixel response time equals total input lag just for the monitor. As an example, let's say that the processor for the monitor is capable of running data through at 120Hz. As mentioned before, this alone would put an average lag into the monitor of around 8ms. Add the response time of the pixels measured GTG or grey to grey and you might have as low as 2ms or 3ms for a decent sized monitor, so you end up with a total minimum lag of 10ms to 11ms before the picture is actually visible on screen. This along with the polling frequency of each device, plus reaction times to audio and video input to the user and you can calculate a rough total input lag. This does vary btw due to the possibility that information is being requested in the middle or near the end of the delay between polls.
Yes, but what I tried to put straight is that the delay due to the refresh rate is something you never can get rid of. It's always there and is a separate delay from the input lag. Both exist together and must be added up to get the total display lag.
Thanks gearjammer. Ya novis, I guess you can say that those other things sort of in a way add to the input lag as well, i dont disagree,
I think Gearjammer said exactly the same thing that I did, but glad he did it in a better way. The monitor can't do any pixel processing before it get the pixel data and the time to recieve pixel data from the graphics card is only dependent on the refresh rate. The display input lag will only occur after that and no the refresh delay doesn't add to the monitors input lag (but I think you ment total input lag). Not sort of in a way but the way it is...
No as gearjammer explained all lcds and plasmas have a processing time, these vary greatly from monitor to monitor, it doesn't matter if the screen is 50hz, 60hz, 120 hz, etc. There is a processing time, a thinking time, before the image is drawn onto the screen. This is where most input lag comes from. For further proof of this, some tvs have a "game mode" where the tv shuts off some of the post processing in order to lower some of the input lag, the picture might suffer a bit because the tv isn't using all it's fancy post-processing powers to do it's magic though, but most people, especially gamers, won't care, or even be able to tell My 23 inch 60 hz lcd monitor (Samsung PX2370) is one of the lowest I have ever seen at only 3.3 ms input lag (measured on average over a 30 frame period). On the other hand, my dad's 50 inch plasma panasonic tv with 0.001 ms gtg response time (plasmas dont suffer from response time/ghosting) has somewhere between a massive 40-80 ms input lag. As you can see the response time can be almost 0 (0.001 ms) but still have lots of input lag, because they are completely independent of each other. Trust me, I've been reading about input lag for over a year. Once i experienced it first hand and it ruined my driving on my first monitor, I got obsessed about it. It's pretty much the only thing I go by when looking to buy a new monitor (and decent size).
So what you are saying is that the monitor is able to do pixel processing before pixel data is sent to it? Because the pixel processing isn't done on the graphics card. Please re-read post #42 again. Gearjammer, it up to you...
No, you are not understanding, there is a delay from the time the GPU sends data to the monitorr to the time the monitor starts displaying the data. I tried proving it to you with different scenarios, different explanations and experiences, etc. I don't know the exact sciences of the process. If you don't believe me that's fine, but people have known about this for many years now, manufacturers know about it, people test it, professional review sites measure it, people experience it, people can even see it (if it's bad enough), etc etc etc etc. Just google it and learn about it. I don't know why you keep debating with me, when its something everyone knows about and proved. Just go research the subject and try reading and learning, rather than just constantly doubting me in such a condescending way.
Lol, I know the easy part of it and I described it here: http://isiforums.net/f/showthread.php/9888-Input-lag-measurements?p=135986&viewfull=1#post135986 Ignore it if you like it's up to you. The refresh rate is there because the graphics card and the monitor need all that time to transfer the display image. It just not an imaginary limit to be evil so that we would get crappy images and delays. If we can agree that the monitor needs pixel data to do anything, can we also agree that the time needed to send all this data is the refresh rate? The monitor input lag includes all possible pixel processing and the display pixel activation time. I think that is what you are talking about. However that accurs after pixel data is transfered to the monitor and cannot hide the transmission delay in any way. Period. I debating with you as you keep on telling that the refresh rate doesn't influence the lag. That is wrong. You keep saying that the delay due to refresh rate is hidden by the input lag. That is also wrong, they are two independet delays.
Novis, you are not understanding what is happening as far as input lag. When the graphics card sends data to the monitor, the monitors processor takes the data and processes it. From that point it is sent to the display where it is drawn. The processor will take a specific amount of time regardless of what is being sent and what is being received. As an extreme example. Your graphics card sends 1 pixel of information to the monitor. On a CRT monitor, the pixel information is sent directly to the color gun and drawn right away as there is no processor involved, so no delay. On an LCD or Plasma display, the information has to go through a processor, or CPU if that helps you think about it more clearly, and then gets send to the display to be drawn. The CPU that is built into the monitor is creating the input lag, not the time to draw the screen. If there were a way to disable all processing of the image before it was displayed on the screen, then you could effectively reduce the input lag of the monitor.
Hell I must be bad in writing because I thought I had written that all the time too. Maybe display should be replaced with monitor/screen or whatever in a few places, I don't really know where to draw the line.
heheh, yep, you had it right there, I guess we all need to read a little more carefully? What you and Spinelli are saying combined would give the total picture of the input lag. There will always be a delay caused by the processor as well as the pixel response time, that can't be overcome at all and is a constant. Refresh rate and everything else just add to that delay.
