Heh, that they work in similar ways, I think you could prove the necessity of that:

Consider what both are doing: filling a screen of millions of pixels, from a few signal lines.

Right off the bat, it's obvious we can't connect single pixels. Millions of signals, that's preposterous at any level. Even connecting individual rows or columns, isn't really useful. You'd need a 223-signal connector just to drive the rows for an NTSC monitor, and you still need some way to drive the columns, some kind of multiplexing.

So to even begin to be practical, we need to multi-multiplex our pixels.

Geometrically speaking, we want to project a volume -- video spans two spacial dimensions and one time dimension. We can construct that volume however we like, but simple geometric shapes will be the easiest, and anything that requires additional circuitry or mechanics to deal with synchronization, or variable bandwidth, distortion, etc. will be very quickly impractical.

And then, whatever our multiplex encoding method is, it will map to the axes of that geometric space.

The cube, cylinder and sphere are the simplest. Consider some of their attributes:

- A cube is the extrusion of a square, which is the extrusion of a line segment.

- More generally, a skewed, unequal-sided cube is a parallelepiped (the 3D equivalent of a parallelogram). The rectangular prism is the special case when the axes are orthogonal, and the cube when the axes are orthogonal and equal. We probably want this case, to avoid dealing with non-square pixels and consequent distortion.

- A cylinder is the extrusion of a circle, which is the revolution of a line segment.

- A sphere is the revolution of a circle, which is the revolution of a line segment.

We can perform a geometric extrusion by scanning a raster: we project a dot or line, then move it relative to the projection screen. If we do this twice, we can go from a pointlike signal to a flat surface, and thus turn a 0-D signal into a line, into a plane, and finally animate that to get our full video experience.

We can perform a revolution in the same way, but it's less obvious how this would be constructed electronically. A mechanical implementation might scan the signal onto a line, then rotate the line physically. That gives us a POV spinner. This has the expected downsides: the intensity varies with radius (the central pixels are moving less than the outer ones), and the pixel resolution is inconsistent (leading to a circular streaking appearance towards the edge). We can at least solve the resolution electrically (committing more bandwidth to the edge pixels than the central ones), but this is a challenge -- if we didn't have an FPGA or fast CPU to do it, we'd have a real problem.

The signal can also be double-revolved, which has the advantage of spherical symmetry -- it looks the same from any angle (assuming we've solved the uniformity problems, of course).

All of this says nothing about the sort of multiplexing -- merely that it exists. Anything doing a scan, has to be time-division multiplexed (TDM), including the mechanical types. TDM seems to be the simplest case. We could of course choose frequency instead (FDM), but it will require a lot of signal analysis to get at.

Which... heh, that's actually a bit interesting, for two reasons:

1. We could make a POV spinner by driving LEDs from an array of bandpass filters. The bandwidth of each filter is proportional to its center frequency, which is proportional to its radius on the spinner. Thus we automatically get more bandwidth as we go out. Downside: it's not easy to construct arrays of bandpass filters!

2. Spectrograms have been used as auditory steganography for some years. This really depends on the availability of "waterfall" spectrogram displays in common audio editing tools, without which, it sounds funny like there's something going on, but you can't really tell until you see the transform. It would be a right pain to construct live video this way (again, you'd want a reasonably powerful CPU or FPGA to do the work), but it would drop directly into to the above setup!

Anyway, multiplexing also requires bandwidth. Obviously, you need ~X * Y * FPS bandwidth. NTSC needed a few MHz, which is a good example of the smallest commercially viable bandwidth, give or take. VGA used low 10s of MHz, and it's gone up over time since.

Wires in cables, offer 100s of MHz bandwidth without too much effort -- pretty typical for a coaxial or twisted pair of modest length (some meters, perhaps up to 100s of meters when done with care).

So multiplexing is a fine choice, and it seems TDM is the simplest and best option.

What about the multiplex format, then? If we did a polar coordinate transform, we could transmit pixels in a spiral. Tricky though: the number of pixels per ring varies with radius, so we need to be very careful with timing.

The simplest TDM multi-multiplex, with consistent timing and bandwidth (fixed pixel clock), is a square raster. Don't have to worry about pixels per ring, or intensity or shape or anything, it's all equal.

We could still quibble about scan direction, whether we're doing it by rows back and forth (lawnmower scan) or all one direction or what; but here again, the simplest case is probably best, and anything more elaborate will only be more and more complicated.

For the CRT, it makes particular sense to scan in the same order (e.g., left to right, top to bottom): if the scans alternated direction (making a zig-zag down the screen), you'd need perfect deflection linearity on both phases of the waveform. Probably more work to solve; plus a bidirectional deflection driver is required. (An actual electrical concern back in the days of expensive and unreliable vacuum tubes! The sawtooth sweep is easily solved with a single driver.)

For the LCD, it also makes sense to scan in the same order: if the pixel address increments linearly, then it can simply overflow (or compare and reset to zero), little logic required. If the scan reversed every row, you'd need more logic to compute the increment/decrement.

Plus, an alternating direction would be annoying. Say, if it ever got out of sync and dropped a row, the whole image flips! Or for the CRT, the vertical scan needs to be a staircase linked to the horizontal sweep, or else the rows will have a subtle taper from edge to edge.

So I think it's very reasonable actually, that LCDs would be driven in the same way.

Internal to the LCD, there is row buffering, level conversion (translating digital bytes into analog pixel driver voltages), and physical addressing -- row and column drivers. Which means... we do in fact use enormous 2000+ signal cables after all, they're just very short, and etched directly onto the glass.

(Or occasionally hot-bar bonded between glass and driver boards. Plasma TVs, too.)

Tim