3 ms·

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

by 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.
    - jbeda 14y ago
      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 :)
      - ori_b 14y ago
        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?
        jbeda 14y ago
        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.
MichaelGG 14y ago
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 14y ago
  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 14y ago
    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...
anonymous 14y ago
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.

by jbeda 14y ago

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.
  - jbeda 14y ago
    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 :)
    - ori_b 14y ago
      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?
      - jbeda 14y ago
        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.

MichaelGG 14y ago

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

anonymous 14y ago

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.