Subpixel vs. Greyscale Antialiasing

We faced this issue when building WPF/Avalon ~7-8 years ago.<p>One key here is that subpixel rendered text can't be easily composited. You essentially need RGB alpha channels so that you can blend each channel independently. Because of this if you want to build a compositing tree with bitmap caching it is very hard to do blending in hardware.<p>One of the lead engineers did some experiments at the time where he put together blind test of cleartype vs. high quality sub-pixel positioned, gamma correct blended grayscale text. I don't think anyone could really tell the difference. These will only get closer as resolutions increase.<p>The lesson is that the big 'wow' factor when cleartype was introduced was the fact that glyphs were now positioned on subpixel boundaries (instead of pixel snapping the glyph origin) and use a gamma corrected blend. The tri-channel blending was only a small part of the picture.<p>But -- cleartype was a unique differentiating feature and was shipped anyway.

&#62; The way to resolve this issue is to start out with greyscale antialiasing on the element.<p>no. The way to resolve this is to leave font rendering alone and hope for WebKit to fix the issue with 3dtransform so that at some point, it'll be able to use subpixel antialiasing everywhere.<p>And even if you insist on forcing grayscale on me, even though I find the subpixel one way, way more readable, then please use the official way to specify antialiasing (-webkit-font-smoothing) and don't rely on a bug by using transform3d.

I have often wondered why Quartz and other renderers don't support subpixel rendering at a lower level. All you have to do is oversample everything by 3x horizontally (actually, even 2x works pretty well) and then pass it through a relatively simple scaling filter after final compositing. It doesn't make much diference for natural images, but anything vector with hard edges looks noticeably better with subpixel redering, and horizontal animation looks smoother regardless of the type of image. And if it were done at a low level like that, there would be no notion of switching smoothing modes during an animation.<p>I suppose a major problem is that this would require all programs to support the notion of non-square pixels, and it's late in the game to expect that. And once we have retina displays everywhere, the whole point will be moot.

Reminds me of Anti Grain Geometry.<p>There is a nice article on text rendering at <a href="http://www.antigrain.com/research/font_rasterization/index.html#FONT_RASTERIZATION" rel="nofollow">http://www.antigrain.com/research/font_rasterization/index.h...</a>

In Chrome 19 on Linux the linked demo does not exhibit any changes in aliasing when clicking the boxes. Does anyone experience different results in Chrome on Windows or OS X, or perhaps Safari?

I was trying to create a website that used Lucida Sans/Grande as body text, and no matter what I tried it didn't look as good as it is on Apple's website.<p>Fired up web inspector and I was surprised to find they use body {-webkit-font-smoothing: antialiased;}

By the way, Mac OS seems to turn of subpixel AA on a lot of external monitors (it did it for me on a Dell Ultrasharp), making text look really bad.<p><pre><code> defaults -currentHost write -globalDomain AppleFontSmoothing -int 2 </code></pre> To fix it.

I ran into a similar problem with the Google Mobile AdSense animation on iOS Mobile Safari. Basically when you put an absolutely positioned element with higher z-index over the iframed ad, it'll trigger greyscale antialiasing. Here is a demo (see it in Mobile Safari): <a href="http://newtonapple.github.com/frontend_tidbits/mobile_safari/iframe_animation_text_rendering_bug/adsense_bug.html" rel="nofollow">http://newtonapple.github.com/frontend_tidbits/mobile_safari...</a>

Are some of the boxes supposed to say "This box is using greyscale antialiasing"? They all say "subpixel" for me.