When will traditional monitors come to a point where they are infeasible?

First; turning on and off backlight stuff:
Chalnoth said:
That still doesn't make any sense, because our eyes will superimpose the images anyway at 60Hz.
But you'll still get less blur. Why turning of backlight during the pixels switching time is a good thing:

1. You'll only get the blur from your eyes instead of blur from your eyes+blur from changing pixel.

2. Less blur while tracking fast moving objects. (note: this is not a good thing, in RL a object will look sharp no matter how fast it moves as long as your eyes are able to track it) Your eyes will track the object in a continuous motion while the object will stay stationary for a 16ms. If object is moving at 10 degrees per second you'll get 0.16 degree wide blur. If the backlight is only on for 1ms you'll only get a 0.01 degree wide blur. You can see this effect on CRTs too, if refreshrate is higher than framerate. On a CRT, if you track a fast moving object drawn at 60fps with 60hz refresh, the object will look sharp. If the refreshrate is 120hz but framerate is still 60hz then the object will look like to superimposed objects (blurred).

3. With constant on backlight, scrolling objects can end up with the wrong color. Example: If you slowly scroll black text over a white background, and the black to white transition is faster than the white to black transition, the text will look lighter than it should while scrolling. If the white to black transition is faster, it will look darker. If the backlight is only on when the pixels have correct color you avoid this problem.


Why turning of backlight during the pixels switching time is a bad thing:

1 Low refreshrates will start flickering just like CRTs


And now; 10bit color stuff:
squarewithin said:
Because it steals the extra 6 bits from the alpha channel, you can't use it for games
It only steals alpha bits from the framebuffer, and most games don't use destination alpha. So, most games could use it.
 
Fox5 said:
I'm not sure if I can say the CRT flickering was better or worse though. My CRT had a 100hz refresh rate, and I never noticed flickering, but when I got my LCD I could have sworn the back light was flickering. (is there some natural flicker induced from the 60hz power used?) It was such an eye strain, and I couldn't even turn the brightness down to make it barable as the image quality went to complete crap when I did that, so I had to leave it overbright until I got used to it.

I do prefer an image that is much easier to see with ambient light, LCDs have no glare and don't fade as easily as a CRT image.

LCD's do flicker, nice tests are at http://www.techmind.org/lcd/index.html
 
Thowllly said:
First; turning on and off backlight stuff:

But you'll still get less blur. Why turning of backlight during the pixels switching time is a good thing:

1. You'll only get the blur from your eyes instead of blur from your eyes+blur from changing pixel.
I'm not seeing it. When the backlight comes back on, you still have to contend with the response time of the pixel.

2. Less blur while tracking fast moving objects.
Not at all. You're still rendering discrete frames: there is zero blur, regardless of what the display is doing. What you may be seeing is some persistence in the display, which is entirely different, and replicated in the eye anyway if response times are fast enough (~20ms or so for high-contrast).

And now; 10bit color stuff:

It only steals alpha bits from the framebuffer, and most games don't use destination alpha. So, most games could use it.
Could, but don't. It'd be fantastic as a rendertarget for HDR rendering, but I have yet to see anybody do that.
 
Chalnoth said:
Could, but don't. It'd be fantastic as a rendertarget for HDR rendering, but I have yet to see anybody do that.
What would be? 10-10-10-2? Hardly, and only the X1800 support it anyway. 8-8-16 is what we need (all integer), with a more programmable blending pipeline, but by the time that's mainstream - if it ever is - there'll be a better alternative out there already, I'm sure. heh.

Uttar
 
Sure, 10-10-10-2 would be great for the output of tonemapping, at least for CRT's (if there's a 10-bit DAC and the range on the 10-10-10-2 format is [1,0], which I'm not certain ATI's is). Why in the world would you want 8-8-16??
 
Chalnoth said:
I'm not seeing it. When the backlight comes back on, you still have to contend with the response time of the pixel.
The point is, the backlight only comes on after the pixels are done changing, and turns off when they're about to start changing again.

Not at all. You're still rendering discrete frames: there is zero blur, regardless of what the display is doing. What you may be seeing is some persistence in the display, which is entirely different, and replicated in the eye anyway if response times are fast enough (~20ms or so for high-contrast).
Yes there is zero blur in the rendered image, the blur is added by your eye. Because the eye is tracking in a continuous motion while the object is standing still before jumping to its next location, the object is moving relative to the eye and you get blur, even though the object is on average moving at the same speed as the eye tracks and there shouldn't actually be any blur. In RL, as long as the eye is capable of tracking an object, it will not blur no matter how fast it's moving.

Also, could you actually bother to read my explanation for the phenomenon? I actually backed up my statement, but you cut that away when you responded. It's of course OK to do that to save space, but you apparently have responded to your cutdown version of my statement, totally ignoring the explanation i gave. This phenomenon is not something I've made up, it's well known among film directors among others...

Could, but don't. It'd be fantastic as a rendertarget for HDR rendering, but I have yet to see anybody do that.
Yes, I know they don't, I was only correcting his statement that it would not be possible because of the lost destination alpha bits. And I disagree that it'd be a fantastic as a rendertarget for HDR rendering, the format being discussed here is only fx10.
 
First of all, I misspoke, I meant that 10-10-10-2 would be fantastic as a rendertarget for the tonemapping pass for HDR rendering (i.e. use FP16 for normal rendering, then 10-10-10-2 for output to the display). Sorry about that.

Secondly, I did read your explaination, and I contest it. Besides, I have another counter argument:

In order for the blanking to work in an LCD, you'd need to have refresh rates higher than the 60Hz they currently operate at (at least 85Hz), which is not only technically challenging to do in terms of display reponse time, but there may also be issues with DVI bandwidth.
 
Back
Top