Stories
Slash Boxes
Comments

Dev.SN ♥ developers

posted by mrcoolbp on Friday March 28 2014, @05:40AM   Printer-friendly
from the 1ms-2ms-3ms-floor dept.

Anonymous Coward writes:

Two years ago John Carmack tweeted, "I can send an IP packet to Europe faster than I can send a pixel to the screen. How f'd up is that?" And if this weren't John Carmack, I'd file it under the interwebs being silly.

Not convinced? You aren't alone, but Carmack appeared when called out to defend this claim.

We looked further and found this informative article from AnandTech about input lag.

 
This discussion has been archived. No new comments can be posted.
Display Options Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Informative) by Boxzy on Friday March 28 2014, @07:16AM

    by Boxzy (742) on Friday March 28 2014, @07:16AM (#22456)

    Were always superior for input lag. They had actual variable resistors to control things like contrast, brightness, hue and volume.

    Now, every display has to have its own computational engine, capable of painting the menu system on the screen because its cheaper. Bad engineering means the stream of pixels has to be sent through the computed pipeline the same way the menu is. There's no real reason other than money that the signals can't still be pass-through other than engineering complexity. (still money)

    --
    Go green, Go Soylent.
    Starting Score:    1  point
    Moderation   +3  
       Interesting=1, Informative=2, Total=3
    Extra 'Informative' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 2) by nitehawk214 on Friday March 28 2014, @12:27PM

    by nitehawk214 (1304) on Friday March 28 2014, @12:27PM (#22575)

    You seem to be making two separate arguments.

    First, that direct controls are superior to the stupid OSD on screen controls. I fully agree with this. Even if the monitor makers could design a UI worth a damn, physcial controls are almost always superior. The only issue is that modern monitors have tons of settings that can be changed, so some sort of on-screen will almost always be necessary.

    Secondly, and independently, you argue that analog displays are superior to digital. Do you even recall consumer-grade analog crt screens? Even brand new they were shit, and after a few years of heavy use they were ready for the scrapheap.

    Arguing that your >$1000 professional super-display was superior is useless. Those high end analog displays are easily outmatched in size and quality by mid-range lcd displays of today. Spend >$1000 on a current screen and you get... well I don't know. I haven't had the need to spend more than 250 on a display in more than 10 years, and I haven't had to discard one in as long either.

    --
    "Don't you ever miss the days when you used to be nostalgic?" -Loiosh
    • (Score: 2) by nitehawk214 on Friday March 28 2014, @12:29PM

      by nitehawk214 (1304) on Friday March 28 2014, @12:29PM (#22576)

      Addendum: Actually I do know something you get on modern super expensive displays... lots of monitor controls! Just like in the old days you can have separate buttons for brightness, contrast, etc. Are physical buttons really that expensive?

      --
      "Don't you ever miss the days when you used to be nostalgic?" -Loiosh
    • (Score: 1) by Boxzy on Friday March 28 2014, @04:08PM

      by Boxzy (742) on Friday March 28 2014, @04:08PM (#22670)

      The only place where I argue CRT was ever superior is input lag. In virtually every respect LCD's have exceeded a CRT. LCD's introduced a problem CRT's never suffered with except in a few minor edge cases. Personally I have never been too bothered by tiny amounts of lag until lip-sync becomes a problem.

      --
      Go green, Go Soylent.
      • (Score: 1) by cybro on Sunday March 30 2014, @11:17PM

        by cybro (1144) on Sunday March 30 2014, @11:17PM (#23413)

        You forgot black levels.

        • (Score: 2) by Boxzy on Monday March 31 2014, @04:04AM

          by Boxzy (742) on Monday March 31 2014, @04:04AM (#23478)

          Sure, that would be one of those minor edge cases. Not everybody obsesses about how black is black. "I'll stop wearing black when they invent a darker colour!"

          --
          Go green, Go Soylent.
  • (Score: 4, Insightful) by Foobar Bazbot on Friday March 28 2014, @12:36PM

    by Foobar Bazbot (37) on Friday March 28 2014, @12:36PM (#22581)

    This is bullshit. The presence of an internal framebuffer is strongly correlated to LCD vs. CRT, and not at all correlated to OSD vs. non-OSD.

    The "dumb pass-through screens" were CRTs, fed off a VGA or component source. They received a pixel at a time, and displayed a pixel at a time.

    Almost every current screen is an LCD of some sort, and LCDs don't display a pixel at a time, they display a whole row/column (or depending on the matrix design, some large fraction (usually 1/2) of a row/column) at a time. Neither a true pixel-at-once (VGA/component) nor DVI/HDMI's pixel-serialized-over-ten-bits connection is suitable for directly driving these -- there must be at least a line buffer (or, I suppose, an insanely wide parallel video interface that transfers a line at once). Therefore no LCD screen can really be a "dumb pass-through screen". Moreover, if they are to be useful at any other resolution than the panel's native resolution, as is commonly required, you need at least a ring buffer of multiple lines for good vertical scaling, and it's simplest with a full framebuffer.

    Note that many CRTs weren't dumb screens with a half-dozen pots to twiddle, but had menu systems so everything could be adjusted with the front panel buttons/wheels and the OSD. Yet they implemented OSD overlays without routing the video signal through a framebuffer, because adding a framebuffer, ADCing the video signal into it, blitting an OSD on, and DACing it back out to the CRT proper would have been worse and more expensive than the genlocked overlay these screens actually used. Doing the OSD menu in a framebuffer only became cheaper once the framebuffer was already there (and already causing input lag) for scaling reasons, and that was only needed with LCDs.