{ "numMessagesInTopic": 16, "nextInTime": 395, "senderId": "lQsH1YM82-KrVXJ3dQC3WoU9cGRBMurBYsCFITVy_WNoFw5HTbg3AKFaHoZ5UoijcGp7-R7IDTFb6FWG4fJrd_XT6rUXq9O5K4fbZqJRPg", "systemMessage": false, "subject": "Re: Fluppeteer: Pixel response time", "from": ""fluppeteer" <yahoo@...>", "authorName": "fluppeteer", "msgSnippet": "Thanks for the informative post, Steve. I m a bit worried (after the colour calibration thing) that it sounded as though I was arguing with you; that s not the", "msgId": 394, "profile": "fluppeteer", "topicId": 351, "spamInfo": { "reason": "0", "isSpam": false }, "replyTo": "LIST", "userId": 192443393, "messageBody": "
--- In IBM_T2X_LCD@yahoogroups.com, "sax00axe" <wrightsl@u...> wrote:
\n> My apologies in advance for the length of this post (hey,
\n> fluppeteer is just as guilty...)
\n
\n...as charged. Bad habit, sorry. I'll try to keep this briefer,
\nalthough my apologies for however long it *is*. (At least on this
\ngroup people should have enough screen real estate for
\nlong posts!)
\n
\n> of where increased frame rate is expensive, but the application is
\n> critical is flight simulators. It is my understanding that flight
\n> simulators for commercial aviation use 30 fps, but for military
\n> flight simulation, 60 fps is used. I have been told that the main
\n> reason 60 fps is used for the military is responsiveness.
\n
\nI understand this is a generic problem in virtual reality (and the
\nreason that VR headsets used to give people motion sickness) - the
\nbrain is very perceptive of a lag in response. I suspect it's not a
\nproblem with commercial aircraft because they genuinely take a while
\nto respond, and the agility of an airliner is limited. A modern
\nfighter jet responds very quickly indeed in comparison; the lag
\nbehind where the jet "should be" is greater. Even if there was no
\npsychological disadvantage, I'd expect new pilots to feel
\ndisoriented by the lack of lag when they transition to a real
\naircraft.
\n
\nI doubt this effect is solely down to the enhanced capabilities of
\nthe pilots (although I don't doubt that they have them); I'd expect
\nanyone to feel something was a bit wrong. Enough some computer
\ngamers insist on >40fps before a game is "usable".
\n
\nAside: The pathways in the brain are finely tuned to compensate for
\nthe time it takes signals to reach them. Experiments have been done
\nwith bypassing some nerves electrically, such that people could feel
\ntheir feet touch the ground faster than the signal could carry along
\nthe nerves in the leg. Supposedly this is very disconcerting! In any
\ncase, the perception of lag in this sense is much more sensitive
\nthan the nerve transmission time would indicate.
\n
\nThis is one reason I have some misgivings about nVidia temporally
\ninterleaving two SLI'd cards to achieve a high Viewperf score: I
\nfeel that Viewperf should be emulating interactive apps, and adding
\na (demi)frame of latency is counter to this aim, even if the
\nplayback rendering rate is increased. It's not up to me to call
\nfoul, though; maybe I've misunderstood the aims of the benchmark (or
\nnVidia's technique).
\n
\n> This discussion implies a few things- if the moving images contain
\na
\n> lot of motion, there is no need to drive a display such as T221 at
\n> 3840x2400- even 1920x1200 may be overkill - you can't see the
\ndetail
\n> in a scene with a lot of motion.
\n
\nThe problem with this theory is that it presumes that the eye is
\nstatic. If you look at a spot on the screen then it's true that you
\ncan't make out much detail in an object moving past the eyes.
\nHowever, if the eyes track something moving then a lot of detail can
\nbe made out - stand in a shower and flick your eyes up and down and
\nyou can see spherical water drops; stand by a train window as trees
\nblur past and you can see clear leaves if the eyes choose to follow
\nthem. Scrolling text wouldn't work if this weren't the case.
\n
\nMPEG works because it can copy bits of the image around to reproduce
\nmovement; whatever the eye follows remains sharp. It's certainly
\npossible to reduce video bandwidth further by limiting detail in the
\nportions of the image which are moving with respect to the eye, but
\nit's more complex than limiting it to those bits of the image which
\ndon't move in screen space.
\n
\n> Another implication is that for good motion quality, the time to
\nform
\n> the image need not be too much faster than 1/30 sec- 1/60 sec is
\n> probably overkill.
\n
\nFor non-interactive apps (where latency doesn't matter), you're
\nprobably right, although there may be some "trail" visible below a
\ncertain threshold; certainly a T221 with some 3D graphics on it I
\nsaw at SIGGRAPH had a noticeable trail if the eye followed some
\ngeometry (although I've seen much worse) - whereas I've never
\nnoticed much of a lag in my brief experiences of a T221 in general
\nuse. As for 16ms/60Hz, I'd guess that's a target so that people can
\nreproduce NTSC video without stuttering - we PAL viewers have never
\nreally noticed a problem with 50Hz refresh (which in itself probably
\nhas more to do with phosphor latency). 25Hz stuttering text where a
\n100Hz television gets its interpolation algorithm wrong *is* very
\nirritating, though - I don't know whether US users of 120Hz TVs with
\nthe same algorithmic problems have similar complaints at 30Hz.
\n
\n> Is 21ms quick enough? Maybe...
\n
\nFrankly, no (depending on what it's being used for.) Objects moving
\non a T221 leave a trail where, on some other monitors, they don't.
\nClearly something is less than perfect! Whether it's good enough for
\n99% of users most of the time is another matter; I'm looking forward
\nto mine arriving for all its good points, but I'm accepting that the
\ntrade-off is that I'm better using a second monitor for fast video.
\nIf I was rich enough, I suspect (from seeing one at a distance) I
\nwouldn't object to using one of Apple's 30" 16ms monsters as a
\ntelevision (when it wasn't in use as a monitor), whereas I'd have
\nreservations about using a T221 in that capacity even if stuttering
\nwasn't an issue. I don't think it's just the 21ms to change 90%
\nthat's the issue, but the time taken to change the last 10%.
\n
\nMind you, peered at closely enough, many CRT televisions have a
\npretty shoddy picture too. My 100Hz Sony 32" model, which is
\nsupposed to have a good picture, has dreadful convergence issues and
\nvery limited facilities to correct the image. Since it cost nearly
\nwhat I'm paying for the refurbished T221, I was hoping the picture
\nwould at least match my cheap 15" monitor (given the resolution
\ndifference)... So I probably shouldn't complain.
\n
\n> it takes longer to switch "off". For switching "on" the speed
\ndepends
\n> on the difference between the initial and final state- for small
\n> differences it takes much longer than for large differences (I
\nknow
\n> it sounds weird...).
\n
\nIt does. Interesting; I'll have to go and look up how it works now!
\n
\n> However, I have not seen any reports of just
\n> how great the 16 ms panels are compared to 40 or 50 ms panels.
\n> The motion is probably better, but how much better?
\n
\nI don't know whether they're 16ms panels, but I've seen TFTs with
\nappreciably less of a "ghosting" effect - none that I've noticed, in
\nfact. I'll experiment next chance I have to play with something I
\nknow to be a 16ms panel; magazine reviewers seem happy to play games
\non them these days, at least. Perhaps I've not looked closely
\nenough, though (and neither have they).
\n
\n> Hitachi and others have made
\n> good progress improving the moving image quality of LCDs by either
\n> strobing the backlight or inserting bands of black data into the
\nLCD
\n> raster. Of course, by the time the moving image quality is really
\n> improved doing this, then flicker will be re-introduced :-).
\n
\nInteresting idea, and I'll have a rummage for references, but I'm
\nsurprised that the difference is all that perceptible given that
\n100Hz televisions don't seem to have reduced image quality -
\nalthough varying amount of computing power devoted to motion
\nprediction for the interpolated frames may be the explanation. It
\nmay also explain why running a TV at three times the frame rate (and
\nusing much simpler interpolation) hasn't caught on. I've not been in
\na position to compare the effects, so please don't take "I'm
\nsurprised" to mean I'm doubting the assertion! I'm not sure I like
\nthe idea, though - I'm pretty sensitive to flicker.
\n
\n> frame, dot inversion, etc. There are also new drive schemes such
\nas
\n> pixel-level-multiplexing emerging, where the rows are not
\naddressed
\n> sequentially (not the same as interlace).
\n
\nAgain, interesting. I can see disadvantages in terms of the time at
\nwhich updates happen compared with the sub-frame time offset of the
\ninput pixel, but most of these are just as interfered with by whole
\nframe capture from a modern digital video camera (or film
\nconversion), so I guess the issues are minor.
\n
\n> image sticking, are much more of a problem than response time. For
\n> rapid-action video games, it will be a while until CRT quality can
\nbe
\n> matched.
\n
\nPossibly true; nonetheless, although I don't speak from personal
\nexperience, 16ms panels seem to be pleasing the reviewers - however
\ndiscriminating they may or may not be. :-)
\n
\nAt the moment, I have three reasons for leaning towards a CRT as a
\nsecond monitor: i) high colour depth support, ii) good arbitrary
\nresolution support, and iii) cost per unit resolution/screen size. I
\nwasn't anticipating pixel response to be an issue for at least some
\nrecent TFTs, although I'm aware of the T221's limitations; however,
\nafter your comments I'll certainly "try before I buy" if I decide to
\ngo for a second TFT panel!
\n
\n--
\nFluppeteer