6 ms·

Subpixel vs. Greyscale Antialiasing

41 points by Hondo 14y ago

wbond 14y ago
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?
- Edootjuh 14y ago
  Same here with Chromium 18
- naner 14y ago
  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.
- _delirium 14y ago
  In Chrome 19 on OS X, the last example changes when I click the box, but the one above it doesn't.
- evmar 14y ago
  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/ http://neugierig.org/software/chromium/fonts/ )
- Splines 14y ago
  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.
natesm 14y ago
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 14y ago
  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 http://cl.ly/1D034736323N2f29191c/o
jbeda 14y ago
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.
- ori_b 14y ago
  Apparently it's possible to do it relatively efficiently: http://anholt.livejournal.com/32058.html http://anholt.livejournal.com/32058.html
  - jbeda 14y ago
    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.
    - ori_b 14y ago
      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.
duopixel 14y ago
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;}
pilif 14y ago
> 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_ 14y ago
  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 14y ago
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 14y ago
Reminds me of Anti Grain Geometry. There is a nice article on text rendering at http://www.antigrain.com/research/font_rasterization/index.html#FONT_RASTERIZATION http://www.antigrain.com/research/font_rasterization/index.h...
blt 14y ago
Are some of the boxes supposed to say "This box is using greyscale antialiasing"? They all say "subpixel" for me.
newtonapple 14y ago
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/iframe_animation_text_rendering_bug/adsense_bug.html http://newtonapple.github.com/frontend_tidbits/mobile_safari...

41 points by Hondo 14y ago

wbond 14y ago

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?

Edootjuh 14y ago
Same here with Chromium 18
naner 14y ago
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.
_delirium 14y ago
In Chrome 19 on OS X, the last example changes when I click the box, but the one above it doesn't.
evmar 14y ago
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/ http://neugierig.org/software/chromium/fonts/ )
Splines 14y ago
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.

natesm 14y ago

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 14y ago
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 http://cl.ly/1D034736323N2f29191c/o

jbeda 14y ago

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.

ori_b 14y ago
Apparently it's possible to do it relatively efficiently: http://anholt.livejournal.com/32058.html http://anholt.livejournal.com/32058.html
- jbeda 14y ago
  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.
  - ori_b 14y ago
    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.

duopixel 14y ago

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

pilif 14y ago

> 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_ 14y ago
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 14y ago

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 14y ago

Reminds me of Anti Grain Geometry. There is a nice article on text rendering at http://www.antigrain.com/research/font_rasterization/index.html#FONT_RASTERIZATION http://www.antigrain.com/research/font_rasterization/index.h...

blt 14y ago

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

newtonapple 14y ago

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