
Subpixel vs. Greyscale Antialiasing - Hondo
http://cantina.co/2012/05/18/little-details-subpixel-vs-greyscale-antialiasing/
======
jbeda
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.

~~~
MichaelGG
Wow, I'd love to hear more about this!

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.

~~~
jbeda
You can probably blame me for this, to some degree. We were really trying to
build for the future with WPF and as such wanted to be truly resolution
independent. As such, we (I) locked a px to a 1/96th of an inch. The end
result is that things animated smoothly but that you got blurry lines and poor
edge interaction under lots of circumstances. Text exacerbates this.

One of the things that I had been working on when I left Microsoft was to come
up with a comprehensive 'pixel snapping' system that would start to address
these issues. I was looking at taking ideas form the autohinting systems used
in the font rasterizers. At the time that WPF shipped, it appeared that no one
had picked up that work. I haven't tracked it since then so perhaps things
have been improved.

~~~
MichaelGG
Well, we can just hope high DPI becomes a reality so things look good again.
WPF has fixed its problems by doing the pixel snapping, but other engines like
whatever powers IE9's rendering (and FF, I think) have regressed and prefer
"accuracy" over readability :(. MSFT even admits around half of the users
dislike it, but the justification is that "everyone else is doing it". Oh
well...

------
pilif
> 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.

~~~
pygy_
Actually, his method is optimal.

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
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.

------
yeureka
Reminds me of Anti Grain Geometry.

There is a nice article on text rendering at
[http://www.antigrain.com/research/font_rasterization/index.h...](http://www.antigrain.com/research/font_rasterization/index.html#FONT_RASTERIZATION)

------
wbond
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?

~~~
evmar
Linux Chrome attempts to follow your system settings for subpixel vs not,
which means the behavior in this area is system-dependent.

(I write "attempts" because the rules are complicated:
<http://neugierig.org/software/chromium/fonts/> )

------
duopixel
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;}

------
natesm
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.

    
    
        defaults -currentHost write -globalDomain AppleFontSmoothing -int 2
    

To fix it.

~~~
tonyarkles
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.

Randomly, I happen to have a picture of the subpixels on a Macbook Pro
display. <http://cl.ly/1D034736323N2f29191c/o>

------
newtonapple
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...](http://newtonapple.github.com/frontend_tidbits/mobile_safari/iframe_animation_text_rendering_bug/adsense_bug.html)

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

