Dev.SN

Transatlantic Ping Faster than Sending a Pixel to Screen

posted by mrcoolbp on Friday March 28 2014, @05:40AM   
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.

• Re:Dumb pass-through screens, (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.

  --
  userscript: Expand/Collapse buttons on every comment [userscripts.org]

  Parent

  Starting Score:	1		point
  Moderation		+2
  Insightful=2, Total=2
  Extra 'Insightful' Modifier		0
  Karma-Bonus Modifier		+1
  Total Score:		4