RR G BB G RR G BB G RR G BB G RR G BB G RR G BB G
BB G RR G BB G RR G BB G RR G BB G RR G BB G RR G
Is the upper left pixel in this (RR G BB), which the article seems to assert, or (RR G BB G) ? If I set the screen to entirely black and turn on pixel (0,0), which subpixels will light up (I don't find Figure 1 shows this well enough)? If (0,0) lights up (RR G BB), then the second pixel at (1,0) is (BB G RR) and overlaps the first? If it doesn't overlap, then the second G from the left in the first row is not part of any pixel. If one pixel is composed of two green half-sized subpixels and one each of red and blue full-sized subpixels, then the ratio of screen area to colored subpixels actually is the same for all pixels, it's just that the green subpixel is spread out more and the order of the subpixels is different in each row -- the later would undermine traditional, plain subpixel smoothing that assume a consistent, regular layout on all rows.Notice that if you count subpixel groupings in figure 2, it's exactly 5 pixels across if you use (xx G yy G) subpixel layout (where xx and yy are either RR or BB depending on which row the pixel is on).
I find this paragraph confusing considering the layout given:
You can see from the photo above that each logical pixel on the Nexus One screen contains one green subpixel and either one double-width blue subpixel or one double-width red subpixel. So the red and blue color channels on the Nexus One display each have half as many subpixels (480800/2) as the green channel. Basically, half the red and half the blue spatial information in the 2D image being sent to the display is simply thrown away or spread to the nearest matching subpixel by a convolution or intensity-dispersion process.*
And if (xx G yy G) defines one pixel, then this paragraph's math is just plain wrong:
One way to count raw pixels, ignoring the effect of all the signal processing on the PenTile display, is to calculate total effective RGB triplets on the screen. You can do this by taking a weighted sum of total number of red, blue and green subpixels, and then converting back to an effective screen size. The total number of effective physical pixels, counted using a weighted sum, is (480800/2)2/3 + (480800)1/3 = 256,000, exactly two thirds the claimed total number of pixels (480800=384,000). This is equivalent to a screen with edge dimensions sqrt(256/384)=82% of the claimed length, or (48082%)(80082%) = 392653 = 256k.*
... as the ratio of the areas of each of the subpixels is the same, at least in figure 2.
If green has more prominence in the way the human eye picks up color, then it actually makes sense to spread out the green over separate areas (or different shaped areas) to give greater prominence to the harder to pick up colors of red and blue, which are more concentrated and thus brighter/richer. It seems from figure 1, the subpixel smoothing takes into account that the red and blue subpixels are ordered differently. It's also possible that the subpixel smoothing recognizes that the alternating ordering of red and blue can be exploited along the vertical axis to achieve the following layout (this is two pixels side by side):
RR G BB G
BB G RR G
which is also the same total subpixel area per pixel, but the whole pixels are more square (1.5 subpixels wide by 2 pixels high vs 3 subpixels (6 half-sizes) wide by 1 pixel high).I personally don't see "waviness" in the lines on the screen, but I do see some stippling at the screen edges (easiest to see on an almost fully white lit screen, like the background (not the white border) of the HN content area). This would seem to be caused by the ordering change of R and B subpixels, not of the half-wide G subpixels.