Subpixel vs. Greyscale Antialiasing | Hacker News Reader

Subpixel vs. Greyscale Antialiasing

cantina.co

41 pointsHondo26 comments

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.

Apparently it's possible to do it relatively efficiently: http://anholt.livejournal.com/32058.html

Interesting article -- but that assumes that you have both an RGBA source and an RGBA mask -- twice the RAM. When doing full screen compositing ram is a big deal.

If you are rendering solid color text, the source could be a constant. But if you are doing general composting the source needs to be another bitmap. You effectively use that mask as an RGB alpha channels.

Most text is solid color, as far as I can see. And for colored glyphs, couldn't you upload a single "font texture" with all the glyphs you care about, and clip out the section you want to paint as a series of subimages, as opposed to rendering one large full screen image? It would still use more RAM, but the amount would be limited. And you'd only have to rasterize the splines for the font once.

Sorry if I'm missing something, I'm not a graphics expert at all.

Perhaps I'm not being clear.

In WPF/Avalon we aimed to have a generic scene graph. We were also looking to cache intermediate nodes in the scene graph and do composition of a transform on those nodes. This was to prevent the need to completely rerender a complex scene graph tree on every frame if the transformations were small enough.

The issue arises when you want to composite text onto a background and then further composite that result onto another image. If there is any transparency under the text in the intermediate cached image, cleartype/subpixel antialiasing breaks down.

So -- it is straightforward to figure out how to do a subpixel mask composition, but it is much harder when you want to take that result and composite it further.

This was a while ago so perhaps I'm misremembering though :)

Ok, I think that makes sense. Just to make sure I understood, the problem isn't the text itself, but what happens when the destination surface has an alpha channel or is transformed?

Exactly -- if you composite into a buffer without an alpha channel (such as the final frame buffer) you are cool. If you want the destination to be able to alpha composite further on, you have trouble/complexity.

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.

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.

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

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.

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.

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.

Reminds me of Anti Grain Geometry.

There is a nice article on text rendering at http://www.antigrain.com/research/font_rasterization/index.h...

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?

Same here with Chromium 18

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.

In Chrome 19 on OS X, the last example changes when I click the box, but the one above it doesn't.

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/ )

In Chrome 19 on Windows I don't see any apparent difference. Display is 96dpi at 1920x1200.

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.

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

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.

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

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

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

Reply on news.ycombinator.com