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

Discussion in 'PC Hardware, Software and Displays' started by K.I.L.E.R, Sep 9, 2005.

  1. randycat99

    Veteran

    Joined:
    Jul 24, 2002
    Messages:
    1,772
    Likes Received:
    12
    Location:
    turn around...
  2. Thowllly

    Regular

    Joined:
    Feb 6, 2002
    Messages:
    551
    Likes Received:
    4
    Location:
    Norway
    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.

    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:
    It only steals alpha bits from the framebuffer, and most games don't use destination alpha. So, most games could use it.
     
  3. fromfrom

    Newcomer

    Joined:
    Jul 24, 2005
    Messages:
    5
    Likes Received:
    0
    LCD's do flicker, nice tests are at http://www.techmind.org/lcd/index.html
     
  4. KimB

    Legend

    Joined:
    May 28, 2002
    Messages:
    12,928
    Likes Received:
    230
    Location:
    Seattle, WA
    I'm not seeing it. When the backlight comes back on, you still have to contend with the response time of the pixel.

    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).

    Could, but don't. It'd be fantastic as a rendertarget for HDR rendering, but I have yet to see anybody do that.
     
  5. Arun

    Arun Unknown.
    Moderator Legend Veteran

    Joined:
    Aug 28, 2002
    Messages:
    5,023
    Likes Received:
    302
    Location:
    UK
    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
     
  6. KimB

    Legend

    Joined:
    May 28, 2002
    Messages:
    12,928
    Likes Received:
    230
    Location:
    Seattle, WA
    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??
     
  7. Thowllly

    Regular

    Joined:
    Feb 6, 2002
    Messages:
    551
    Likes Received:
    4
    Location:
    Norway
    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.

    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...

    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.
     
  8. KimB

    Legend

    Joined:
    May 28, 2002
    Messages:
    12,928
    Likes Received:
    230
    Location:
    Seattle, WA
    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.
     
Loading...

Share This Page

  • About Us

    Beyond3D has been around for over a decade and prides itself on being the best place on the web for in-depth, technically-driven discussion and analysis of 3D graphics hardware. If you love pixels and transistors, you've come to the right place!

    Beyond3D is proudly published by GPU Tools Ltd.
Loading...