We faced this issue when building WPF/Avalon ~7-8 years ago.
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.
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.
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.
But -- cleartype was a unique differentiating feature and was shipped anyway.
It seemed that plenty of folks (myself included) found WPF text to be rather unusable until they fixed it years later (after the VS 2010 blurry text editor thing). I can't use IE because of the 'smoothed' text, but Chrome still seems to get it "right" (snaps to pixels, like in Word). Are we talking about the same thing?
At high DPI it does look fine; unfortunately high DPI didn't actually happen like Microsoft thought, just like 6GHz CPUs (both predictions at PDC 2003). Although, now that the iPad3 shipped a high DPI screen, maybe other OEMs will get their stuff together.
Subpixel anti-aliasing, both cleartype on windows and the implementation on linux, have always looked very rainbow-ish to me. It might look smoother to some, but the colours are way too distracting and the first thing I do on a new OS is set fonts to NOT use rainbow-style anti-aliasing.
> The way to resolve this issue is to start out with greyscale antialiasing on the element.
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.
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.
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.
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 don't know if this is still the case, but I know a couple years ago Chrome ignored desktop hinting (on Linux specifically, not sure about other OSes) and handled its own font rendering independently.
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.
Fired up web inspector and I was surprised to find they use
body {-webkit-font-smoothing: antialiased;}
As a quick (not particularly educated) guess, they might be doing that because they don't know what the pixel configuration is on the external display. On their own monitors, they know exactly how the subpixels are arranged.
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): http://newtonapple.github.com/frontend_tidbits/mobile_safari...
[+] [-] jbeda|14 years ago|reply
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.
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.
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.
But -- cleartype was a unique differentiating feature and was shipped anyway.
[+] [-] MichaelGG|14 years ago|reply
It seemed that plenty of folks (myself included) found WPF text to be rather unusable until they fixed it years later (after the VS 2010 blurry text editor thing). I can't use IE because of the 'smoothed' text, but Chrome still seems to get it "right" (snaps to pixels, like in Word). Are we talking about the same thing?
At high DPI it does look fine; unfortunately high DPI didn't actually happen like Microsoft thought, just like 6GHz CPUs (both predictions at PDC 2003). Although, now that the iPad3 shipped a high DPI screen, maybe other OEMs will get their stuff together.
[+] [-] anonymous|14 years ago|reply
[+] [-] ori_b|14 years ago|reply
[+] [-] pilif|14 years ago|reply
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.
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.
[+] [-] pygy_|14 years ago|reply
When the bug is fixed in Webkit, the translation will become a no-op, and you'll get sub-pixel AA everywhere.
Meanwhile, the font rendering is consistent in animations.
[+] [-] mistercow|14 years ago|reply
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.
[+] [-] yeureka|14 years ago|reply
There is a nice article on text rendering at http://www.antigrain.com/research/font_rasterization/index.h...
[+] [-] wbond|14 years ago|reply
[+] [-] evmar|14 years ago|reply
(I write "attempts" because the rules are complicated: http://neugierig.org/software/chromium/fonts/ )
[+] [-] Splines|14 years ago|reply
I checked on my iPhone 4S and when I zoom in I can see a difference (that I might be missing on my desktop). It is incredibly subtle.
[+] [-] naner|14 years ago|reply
[+] [-] _delirium|14 years ago|reply
[+] [-] Edootjuh|14 years ago|reply
[+] [-] duopixel|14 years ago|reply
Fired up web inspector and I was surprised to find they use body {-webkit-font-smoothing: antialiased;}
[+] [-] natesm|14 years ago|reply
[+] [-] tonyarkles|14 years ago|reply
Randomly, I happen to have a picture of the subpixels on a Macbook Pro display. http://cl.ly/1D034736323N2f29191c/o
[+] [-] newtonapple|14 years ago|reply
[+] [-] blt|14 years ago|reply