While "appeal to authority" is generally a bad way to end a discussion, I will start by pointing out that this is Alvy Ray Smith writing, and he was writing in 1995. So while you could end up disagreeing with him (though I hope you wouldn't), you might consider why he was writing. Your comment shows that this paper is just as applicable today.
(since you stopped on page two you never saw the several examples of why this matters in the article, including one on scanning and one on pre-rendering geometric computation).
Those graphics cards you refer to reflect Smith's influence on their design.You have sub pixel rendering today because pixels aren't squares. This was computationally prohibitive in 1995.
The TL;DR of this brief paper is "IO is really really hard, and though accepting shortcuts and defaults only kinda works and here's why." You benefit from a lot of work done in the last 20 years to improve the quality of the libraries and hardware available to you, but still, "photo-realistic" graphics aren't.
By the way, rendered pixels weren't squares in those days (they were not-always-circular dots on a screen which itself wasn't flat) and they aren't on today's flat LCDs (you can think of them as rectangular, though the color elements do not present uniformly though the area) and they sure as hell aren't on any device with lenses or mirrors (including projectors and headsets)
> You have sub pixel rendering today because pixels aren't squares.
Another way to put this is that color LCD panels don't have pixels at all. The only thing they have is red, green, and blue "subpixels" that each have a 1:3 aspect ratio. So you could take any three of those subpixels in a row and call them a "pixel".
Operating systems were traditionally written without any knowledge of these individual subpixels, and addressed the display on a whole-pixel basis. It's up to the display hardware to figure out how to map colors onto the physical device.
But if you know you're rendering on an LCD with the 1:3 subpixels, and you know the order of those subpixels (usually RGB, sometimes BGR), then you can give each "pixel" a color that lights up the individual subpixels as you want.
As an aside, in CSS you can think of a color value like "rgb(10,20,30)" as addressing the individual subpixels, assigning 10, 20, and 30 to the red, green, and blue subpixels. You just don't know how those physical subpixels are laid out on the display, so you can't really do subpixel rendering in CSS.
But if the OS knows what order the subpixels are in, it can take advantage of that. Even though the display hardware/firmware presents an abstraction of "pixels", the OS still provides individual R, G and B values for each "pixel" - thus addressing in a roundabout way the individual subpixels.
That's what makes subpixel rendering possible on displays that don't directly expose the individual subpixels.
> rendered pixels weren't squares in those days (they were not-always-circular dots on a screen which itself wasn't flat)
The circular dots on a CRT aren't pixels and aren't directly related to pixels at all. Assuming a traditional non-Trinitron CRT, you have three electron guns for R, G, and B. The beams from these guns go through a shadow mask with little holes in it, and then the beams hit phosphor dots on the screen. The shadow mask allows each beam to light up only the phosphor dots for that color.
As the electron beams sweep across the CRT, each horizontal sweep corresponds to a row of pixels, and the three beams are modulated brighter or dimmer for each individual pixel. But there's no relationship between the size and location of these "pixels" and the actual shadow mask holes or phosphor dots on the screen. CRT displays could run in multiple resolutions but obviously the phosphor dots couldn't move to line up with the pixel locations for each resolution.
Trinitron displays were are a bit different, using phosphor stripes instead of dots and an aperture grille (tiny vertical wires under tension) instead of a shadow mask with holes in it, but the principle was the same: The phosphor stripes didn't correspond at all to pixel locations.
/Both/ relies on the fact that a pixel has an area, i.e. it is not a point, which is the point I was trying to make.
A pixel on LCDs is indeed square most of the time, the subpixel elements are not. CRTs, of course, different story.
All the "problems" he describes actually arise from the misconception that a pixel is a /point/ sample. It is an area sample, and if you treat it as such, the rest follows.
So, when zooming in on a pixelated image, how do we fill in the gaps between the pinholes? Declaring pixels to be square areas means that larger views of a given image really should be composed of larger, hard-edged squares for each source pixel. I.e point sampling is truth.
The reality is that what's really between the pixel centerpoints is unknown --lost forever or never calculated at all. To fill in the gaps we can only make intelligent guesses. Therefore: sampling theory.
Are you sure? In my experience, it depends on the context, but the pixels themselves are _not_ always of equal height:width ratio.
I took it to mean, "yes, many times over." As in, without a doubt, all pixels are square.
My error.
edit: I do feel we are all smart enough to realize that the circle-vs-square, when considering a single channel, isn't affected much when colors are then considered
offsets for each color are not unimaginable
Anti-aliasing is a direct result of the fact that pixels are point-samples--the idea is to combine multiple samples and weight them so that the collection of point samples (in the form of a frame buffer) still represents a perceptually-reasonable form of the image.
You say it yourself: Since solving the integration over the pixel area is generally hard, we approximate the integration with multiple point samples.