Re:A Pixel Is Not a Little Square (1995) [pdf]
by Stratoscope on Sunday November 16, 2014 @04:07PM
(#8615431)
A couple of things in your interesting comment were a bit confusing to me. Since you obviously know your stuff, it may be just a difference in terminology that thew me off. So let me add a couple of notes that hopefully may help clarify for others.
> 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.
> 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.