Display Lag and Response Time
One of the areas where the A-MVA panel does extremely well is in the areas of display lag and pixel response time. Just to recap, you may have heard complaints about "input lag" on various LCDs, so that's one area we look at in our LCD reviews. We put input lag in quotation marks because while many people call it "input lag", the reality is that this lag occurs somewhere within the LCD panel circuitry, or perhaps even at the level of the liquid crystals. Where this lag occurs isn't the concern; instead, we just want to measure the duration of the lag. That's why we prefer to call it "processing lag" or "display lag".
To test for display lag, we run the Wings of Fury benchmark in 3DMark03, with the output set to the native LCD resolution - in this case 1920x1200. Our test system is a quad-core Q6600 running a Radeon HD 3870 on a Gigabyte GA-X38-DQ6 motherboard - we had to disable CrossFire support in order to output the content to both displays. We connect the test LCD and a reference LCD to two outputs from the Radeon 3870 and set the monitors to run in clone mode.
The reference Monitor is an HP LP3065, which we have found to be one of the best LCDs we currently possess in terms of not having display lag. (The lack of a built-in scaler probably has something to do with this.) While we know some of you would like us to compare performance to a CRT, that's not something we have around our offices anymore. Instead, we are looking at relative performance, and it's possible that the HP LP3065 has 20ms of lag compared to a good CRT - or maybe not. Either way, the relative lag is constant, so even if a CRT is faster at updating, we can at least see if an LCD is equal to or better than our reference display.
While the benchmark is looping, we snap a bunch of pictures of the two LCDs sitting side-by-side (using a relatively fast shutter speed). 3DMark03 shows the runtime with a resolution of 10ms at the bottom of the display, and we can use this to estimate whether a particular LCD has more or less processing lag than our reference LCD. We sort through the images and discard any where the times shown on the LCDs are not clearly legible, until we are left with 10 images for each test LCD. We record the difference in time relative to the HP LP3065 and average the 10 results to come up with an estimated processing lag value, with lower numbers being better. Negative numbers indicate a display is faster than the HP LP3065, while positive numbers mean the HP is faster and has less lag.
It's important to note that this is merely an estimate - whatever the reference monitor happens to be, there are some inherent limitations. For one, LCDs only refresh their display 60 times per second, so we cannot specifically measure anything less than approximately 17ms with 100% accuracy. Second, the two LCDs can have mismatched vertical synchronizations, so it's entirely possible to end up with a one frame difference on the time readout because of this. That's why we average the results of 10 images, and we are confident that our test procedure can at least show when there is a consistent lag/internal processing delay. Here is a summary of our results for the displays we have tested so far.
|Display Input/Processing Lag vs. HP LP3065|
As you can see, all of the S-PVA panels we have tested to date show a significant amount of input lag, ranging from 20ms up to 40ms. In contrast, the TN and S-IPS panels show little to no processing lag (relative to the HP LP3065). The BenQ FP241VW performs similarly to the TN and IPS panels, with an average display lag of 2ms - not something you would actually notice compared to other LCDs. Obviously, if you're concerned with display lag at all, you'll want to avoid S-PVA panels for the time being. That's unfortunate, considering S-PVA panels perform very well in other areas.
Despite what the manufacturers might advertise as their average pixel response time, we found most of the LCDs are basically equal in this area - they all show roughly a one frame "lag", which equates to a response time of around 16ms. In our experience, processing lag is far more of a concern than pixel response times. Taking a closer look at just the FP241VW, we can see the typical one frame lag in terms of pixel response time. However, the panel does appear to be a little faster in response time than some of the other panels we've tested (notice how the "ghost image" isn't as visible as on the HP LP3065), and we didn't see parts of three frames in any of the test images.
Update: What Causes Display Lag?
After the initial article went live, one of our readers who works in the display industry sent me an email. He provides some interesting information about the causes of image lag. Below is an (edited) excerpt from his email. (He wished to remain anonymous.)
PVA and MVA have inherent drawbacks with respect to LCD response time, especially gray-to-gray. To address this shortcoming, companies have invested in ASICs that perform a trick generically referred to as "overshoot." The liquid crystal (LC) material in *VA responds sluggishly to small voltage changes (a change from one gray level to another). To fix this, the ASIC does some image processing and basically applies an overvoltage to the electrodes of the affected pixel to spur the LC material into rapid movement. Eventually the correct settling voltage is applied to hold the pixel at the required level matching the input drive level.
It's very complicated math taking place in the ASIC in real time. It works well but with an important caveat: it requires a frame buffer. What this means is that as video comes into the panel, there is a memory device that can capture one whole video frame and hold it. After comparing it to the next incoming frame, the required overshoot calculations are made. Only then is the first captured frame released to the panel's timing controller, which is when the frame is rendered to the screen. As you may have already guessed, that causes at least one frame time worth of lag (17ms).
Some companies discovered some unintended artifacts in their overshoot calculations and the only way they saw to correct these was to allow for their algorithm to look ahead by two frames instead of one. So they had to up the memory of the frame buffer and now they started capturing and holding not one but two frames upon which they make their complex overshoot predictions to apply the corrected pixel drive levels and reduce gray-to-gray response time (at the expense of lag time). Again, it works very well for improving response time, but at the expense of causing lag, which gamers hate. That in a nutshell is the basis of around 33ms of the lag measured with S-PVA.
[End Excerpt - the following is not from our reader]
Not every display uses this approach, but this could account for the increase in display lag between earlier S-PVA and later S-PVA panels. It's also important to note that I tested the Dell 2408WFP revision A00, and apparently revision A01 does not have as much lag. I have not been able to confirm this personally, however. The above also suggest that displays designed to provide a higher image quality through various signal processing techniques could end up with more display lag caused by the microchip and microcode, which makes sense. Now all we need are better algorithms and technologies in order to reduce the need for all of this extra image processing -- or as we have seen with some displays (particularly HDTVs), the ability to disable the image processing.