I have not looked, but let's think about this a second Novis. If an LCD or Plasma monitor were to do a complete frame refresh instead of drawing the screen from top to bottom like a CRT, then we would see no tearing in the image regardless of refresh rate. On the other hand though, it could be that the monitor will fire all the pixels at the same time, reading what ever is in the buffer at the time, even if part of the buffer is still filled with older image data. The second option would lead you to believe that the image at the bottom of the screen would never get refreshed though if you had input to the monitor that was higher than it's refresh rate.
I guess it's nothing more than just an advanced light pen. The device will know when the pixel signal is generated and just measured the time until the pixel light up.
Tearing is caused from that you switch frame buffers on the graphics card in the middle of a frame transfer. It will occur in any of the cases. I believe in the most simple way you update all transistors in an LCD sequencially as they arrive by the pixel clock. Then after the frame is transferred you "strobe" the matrix at refresh to make it emit the new colors. But as I said early in this thread, I'm no display expert.
60hz monitors are behind 120hz monitors 16ish ms to 8ish, so you get double the resolution of updates in between each frame displayed on a 120hz, but once the 60hz does update it's image it is still no more behind and in line delay-wise with the 120hz monitor, then the next frame hits and it is now behind the 120hz monitor visually by 8ish ms, then the next frame hits and it is back in line with no further lag relative to the 120 hz monitor, then the next frame hits and it is 8ish ms behind the 120hz monitor, then the next frame draws and they are back in line relative to eachother again, and so on, and so on, and so on. So once the 60hz monitor updates, it's image is in line and no more delayed than the 120 hz monitor, it's just that the 120hz monitor is doing more of these updates/screen refreshes per second, so you are getting double the updates, and so on every second update the 60hz monitor will be 8ish ms behind the 120 hz monitor yes, but on every alternative 2nd update/every update on the 60 hz monitor, the 60 hz monitor will be back in line even with the 120 hz, and so on and so on. You are getting more in between updates with the 120 hz so when the 120 hz refreshes the 60hz monitor is behind 8 ish ms but the next time 120hz monitor refreshes the 60hz one does too and they are now both refreshed and updated and back in line with each other, then the 120 hz monitor updates and the 60 hz doesn't, so the 60hz is now visually behind the 120 hz by 8ish ms, but then they both update again and they are back in line with each other, repeat, repeat, repeat, over and over.
It can't be that way because there are for example 60 Hz LCD monitors which have total latency of 3,3 ms. Couldn't be possible if whole frame would be stored in buffer before drawing. The line was about A/D conversion (analog to digital) which isn't needed anymore as display signals are already in digital format.
Quoting KeiKeis's monitor review on prad.de: http://translate.google.com/transla.../2010/test-asus-ve278q-teil14.html#Latenzzeit "We measure the Asus VE278Q a delay time of 17.9 milliseconds. Added to this, the average response time is half of 2.4 milliseconds. The mean total latency is thus 19.3 milliseconds. Obviously, this monitor will always store a frame between what a gamer monitor is unfortunately an undesirable property."
That's pretty much the case (and exactly true if monitor is in perfect sync with game engine). However higher update/refresh rate still means lower latency. I think you need to think extremes (like I had to do) to see how it goes so compare situations where one monitor has 0,1 Hz refresh rate and other has 60 Hz refresh rate. At time 0 both show frame on screen which is only 15 ms old and everything is good. One second later driver with 60 Hz monitor is doing great but the guy with 0,1 Hz is still waiting for the next frame wondering if his car is still on track. 2 seconds later guy with 0,1 Hz monitor feels terrible rumbling from his FFB wheel and wonders what the heck is happening. Few seconds later there's huge bang and then perfect silence. At 10 seconds from the start the second frame is drawn to his monitor screen and he's able to see that he had crashed. So higher update/refresh rate means less lag. Just like the brake controller example I wrote few pages ago: I still have to partially agree with your view though. When things are happening fast enough then I believe something like 5 ms difference in latency isn't going to make a difference so at that point it's just experienced as increased smoothness or fluidity.
Yeah it seems my monitor sucks after all. I didn't know about overdrive technology back then. Wouldn't accept a monitor with that property anymore.
Yor monitor is way better than my TV regarding lag . What i wanted to say by quoting is, that the display can either buffer the whole frame (then lag is always > 1/refresh Hz) or update the panel immediately as the signal gets in (how this works i dont know, lag can be < 1/refresh Hz)
I'm no expert on panel technology but I'm pretty sure LCDs still draw line by line during the entire "refresh" just like a CRT.* Technically they could just aswell light every pixel at once but then you'd have to completely re-design how graphic cards communicate with the display and probably also how the display is wired internally. Those cards would then not work with CRTs any more and those screens would not work with old cards (so will never happen). Yay for backwards compatibility! *I'm basing this on an old screenshot I saw on a german site where they rendered a frame with a vertical column of stopwatches at over 3000 fps. Thus the frame buffer was swapped constantly but the display showed different times on every single clock, meaning it only drew the "current line" from the frame buffer as it swept down top-bottom. I can't find the link anymore but I originally found it while searching for LCD refresh rate information, if anyone wants to go on a Google expedition.
I did some reading of input lag measurements at http://www.prad.de/en/monitore/specials/inputlag/inputlag.html. First I thought they did just talk crap but they were discussing old lag measurments methods by using photo methods. Then thay wrote this and I was hooked! I had to read on. Then they started to hook up oscilloscopes to the output of the graphics card and discovered this: And showed that it is not, and then this... And finally draw this conclusion: Can it be that you are running one analog output from the computer or one analog input to a screen? I think they manage pretty well to show that measure lag by using photo recording is pretty meaningless and you need an oscilloscope if you will have any kind of accuracy in the measurement.
Novis: Haha that's exactly the article I meant, I never realized there was an english version so I didn't understand the text, but the image I was referring to is the one on page 9 near the bottom.
Good point! In almost every test they define lag as "the time from the input signal..." which would mean that the input lag would be huge and vary between pixels on the screen if a complete frame refresh was done. Something like this maybe?
I've used DVI (digital) for the reference monitor and HDMI for the TV (it doesn't have DVI) Very interesting artice! (have to fully read and understand it now). It seems my previous lag measurements were very inaccurate. Additionally a lot have changed since then too, graphics driver, graphics card AND TV firmware.
If I don't remember awfully wrong they developed a new photo method which is actually pretty accurate. One just needs their enhanced clock software and need to take the phase difference into account (it can be determined from the photo because timestamps are on individual rows). The method I used described in the first posting of this thread is still rock solid and can be enhanced by switching to faster camera.
These were alot of ideas already and probably will let me find the 50ms 1. Measure lag with KeiKei's method with the TV and the monitor. if the monitor's lag is near to KeiKei's results then ..the lag is on the TV side (or HDMI) else ..either i have the old monitor revision ....find out ..or some unknown lag ....the search goes on again (but already encircled)
Lol you quote a small part of what I say, in order to turn it around out of context to make it sound like you are right. You are impossible to talk to man, theres no point in having a discussion when you act like such a goof, grow up man. Bye.
Huh? You finally said that the 60 Hz monitor will trail the 120 Hz monitor between 0 ms and 16 ms. Trailing means extra lag so the refresh rate matter, or?
