Color-aware ClearType requires access to fixed background pixels, which is a problem if you don't know what the background pixels are, or if they aren't fixed


ClearType is a technology that blends text pixels with background pixels with the goal of reducing visual artifacts during text rendering.¹ If you go for the full-meal version of ClearType, it uses knowledge about the physical properties of LCD screens in order to carry out its work. Some time ago, I noted one catch with this model, which is that overdraw gives the ClearType algorithm the wrong background pixels.

Another gotcha is that if you don't know what the background pixels are at all, then you can't use ClearType. For example, you might be rendering a semi-transparent bitmap that will be drawn on top of other content. If you try to use ClearType to render text onto this bitmap, the ClearType engine will see transparent pixels as the background, and blend accordingly. (My guess is that it will treat them as black pixels.) But when you actually draw this bitmap to the screen, those transparent pixels will allow the pixels below the bitmap to shine through, and those underlying pixels are not transparent.

The result is color fringes because the ClearType engine was given incorrect background pixels.

Another assumption that the ClearType engine makes is that the bitmap will be drawn on exact pixel boundaries without any stretching or shrinking or rotation. Since ClearType is doing math based on the physical LCD, you break the ClearType model if you scale the bitmap, rotate it, or render it on a fractional-pixel boundary because each carefully-crafted ClearType pixel does not end up as a single pixel on the LCD panel. (The mapping of original pixels to transformed pixels is controlled by something called an interpolation mode. For example, Direct2D offers a variety of interpolation modes.)

If you break this rule and use ClearType anyway, you will once again get the dreaded color fringes.

Nearly all of these factors come into play on the Windows 8 Start screen.

The word Start on that page is rendered onto a transparent bitmap because it needs to overlay on top of your Start background, and most of the Start backgrounds are not fixed; they scroll slowly as you pan through your tiles.

The tiles themselves translate when you pan the Start screen, and they scale when you go into Customize mode or when you press them, and they rotate when you tap on them. This means that any text drawn onto a tile cannot use the color-aware version of ClearType.

These concerns apply more generally to any bitmap that will be scrolled. A bitmap that scrolls with subpixel positioning cannot use the color-aware version of ClearType because ClearType assumes integer-pixel positioning. (This is why Internet Explorer doesn't use color-aware ClearType. Scrolling is performed with Direct Manipulation, and Direct Manipulation does subpixel scrolling.)

Now, of course, you could work around this problem. You could design your interface so that it doesn't require transparent bitmaps, say by using fixed backgrounds. And you could design your interface so it doesn't use subpixel positioning, scaling, or rotation. Or you could simply stop pre-rendering text and instead rerender them on-the-fly each time something changes. The first two workarounds impair your design. The second impairs your performance, since moving a bitmap is no longer a simple update of a sprite's coordinates and transformation matrix; you have to go through a full text rendering pass, including a pixel read-back in order to figure out what the current background pixels are. (And pixel read-back from video memory is not cheap since it forces the composition tree to flatten.)

Both trade-offs are pretty expensive, and the cheaper alternative is usually simply to stop using color-aware ClearType.

¹ Yes, there are people who don't like ClearType. The point of today's article isn't about whether ClearType is good or bad; it's about ClearType's limitations. I tried to remain neutral on the subject by saying that improved text rendering is the goal of ClearType, making no statement about whether it achieves that goal.

Comments (47)
  1. M. Dudley says:

    Is rotating an LCD equivalent to rotating a ClearType bitmap? I'm thinking in both cases the subpixels are arranged perpendicular to ClearType's assumed arrangement.

  2. Azarien says:

    It's a pity that high-quality text rendering is no longer a priority for Microsoft.

    Internet Explorer since IE11 i think looks like crap.

    Office 2013 looks like crap.

  3. gdalsnes says:

    To me ClearType always seems to converts the font to a semi bold type. This does not match with the name: Clear = remove stuff. ClearType always adds stuff. A better name would maybe have been FatType.

  4. Koro says:

    All of this would not be a problem if we could have per-channel alpha, say with an hypothetical RGBXAAAX pixel format.

  5. Juan says:

    ClearType is nothing more than font antialiasing. Everybody takes more or less the same approach. They add things to the bitmap based on the color of the background so your eye doesn't see any sharp edges. With high density screens in phones and monitors antialiasing has improved considerably but the issues they face are the same in Windows than in OS X or Linux. I wouldn't blame Microsoft to include it since it makes some people life easier and for others they just can deactivate it.

  6. Christopher says:

    @arghhhhhhhhhhh: You might want to try running the ClearType Tuner to see if it can produce something that's more to your taste. I usually find that the options it offer vary from looking semi-bold to pretty light.

  7. Evan says:

    @arghhhhhhhhhhh: "This does not match with the name: Clear = remove stuff."

    "Remove stuff" is only one of several related definitions of clear. Another is "easily seen; sharply defined" [Random House Dictionary, via dictionary.com].

  8. Joshua says:

    Ah yes the ever-present constraint of realtime rendering imposes limits on maximum rendering. Not valid to assume all machines have a fat GPU (or any GPU at all) so ...

  9. Alexey says:

    Can we not render text on the GPU already?

  10. Jazz Hands says:

    Would the people who feel compelled to opine about how well or poorly ClearType works without referencing the actual technical issues presented in the article please go back and read Raymond's footnote, say, oh, 100000 times, and then come back and comment? Thanks!!

  11. Gabe says:

    The need for subpixel scrolling seems a lot less important than the need for text that's easier to read. I wonder if anybody suggested a means to limit Direct Manipulation to whole-pixel scrolling to allow scenarios where users want to take full advantage of ClearType.

  12. kinokijuf says:

    Is there a way to re-enable subpixel smoothing in IE/Win8.x?

  13. alegr1 says:

    I wonder who was the wise guy who decided to enable FuzzyType in the Windows DVD Setup (and with the MS generic VGA driver, generally).

  14. 12BitSlab says:

    Maybe it's just the hardware I use and the programs I use, but I have always had good luck with ClearType and appreciate the work MSFT did on it.

    I hadn't thought before about how ClearType does its job so I learned something today.

  15. alegr1 says:

    @Juan:

    ClearType takes advantage of the fact that RGBRGBRGBRGBRGB arrangement of the color strips on a LCD monitor can be interpreted as RGB RGB RGB, or as GBR GBR GBR, or as BRG BRG BRG. This allows to draw black vertical lines with 1/3 pixel precision.

  16. IanBoyd says:

    Another instance where you don't know the background color, or if background color changes, is drawing text on non-opaque Glass.

    See the question [on Stackoverflow](stackoverflow.com/.../aero-how-to-draw-cleartype-text-on-glass), which has pretty screenshots demonstrating the issue.

    The solutiion is to use `ANTIALIASED_QUALITY` rather than `CLEARTYPE_QUALITY` if you are drawing on partially transparent glass.

    A mitigating factor is that starting with Windows 8, you will no longer encounter partially transparent glass in the wild; the user is only able to select opaque glass.

  17. Santokes says:

    The day Raymond touched on alpha accumulation and texture samplers.  This blog has no limits!

  18. Ken says:

    @alegr1:

    It's more complicated than that. If you draw a "black vertical line" by dropping all the blue pixels along the line, you actually end up with what appears to be a vertical yellow line. A naïve subpixel text renderer will leave the edges of your text full of color fringing.

    Most of the math that ClearType does is to allow use of subpixels while maintaining the perceived color.

  19. Gabe says:

    Ken: I think you misunderstood what alegr1 was saying. He did't mean that you could draw lines 1/3 pixels thick, just that you can take a vertical line and shift it by 1/3 pixels and still have it be black and 1 pixel thick.

    In other words, the standard way to draw a 1-pixel-thick black vertical line is to just take all the RGB values in a column and make them 0, but you could just as easily use GBR or BRG and you'd still get a black line.

  20. AndyCadley says:

    @koro: I'm not sure per pixel alpha helps. Cleartype actually needs to know the final colours in order to work ok properly, because it has to mitigate certain colour effects that occur otherwise.

    The real solution would be high dpi displays everywhere, because then the need to fake it with tricks like Cleartype would be a lot less.

  21. Yuri Khan says:

    @M. Dudley: You can configure ClearType for an alternate orientation (BGR, vertical RGB or vertical BGR). The problem with LCD rotation is that fonts *need* triple resolution in the X axis much more than in the Y axis.

  22. Sockatume says:

    M. Dudley: Yes, that'd be analogous. I think the Cleartype Tuner offers options for the three possible subpixel arrangements in both horizontal *and* vertical stripe arrangements, so if you've got an LCD set up vertically you can have Cleartype compensate for it.

    On that subject: I noticed that the "modern UI" parts of Windows 8 and its UI didn't use coloured subpixel rendering quite quickly, but I assumed that was because these newfangled tablets were used in lots of different orientations and it wasn't worth the overhead to keep up with the changing subpixel geometry. Your explanation didn't even occur to me.

  23. alegr1 says:

    4K displays will make ClearType unnecessary. They will also break some programs that don't know how to handle high DPI displays. There will have to be another compat shim, to fake an old 2K monitor for them.

  24. Joshua says:

    @Raymond: Read it as "Respect the already existing configuration switches between bilevel, anti-aliased, and ClearType."

  25. Gabe says:

    dmw: I believe WPF uses a mechanism like you describe. I'm pretty sure I've seen WPF render text that's blurry when animating and sharp when static.

  26. Joshua says:

    Despite the fact that alegrl1 decided to use a derogatory name, he has an excellent point. ClearType should *not* be enabled at install or recovery time because there is a very good chance the video drivers that would allow scaling to the monitor resolution aren't available.

  27. xpclient says:

    Are there no user-controllable parameters to tweak the grayscale rendering? The ClearType Tuner built into Windows affects only the color-aware ClearType?

  28. dmw says:

    Regarding the article, I also didn't expect that, and the Direct Manipulation thing certainly explains why IE11 uses ClearType on Windows 7 but does not on Windows 8.x (it doesn't pan with DM simply because there is no DM on Windows 7).

    I'm okay with no ClearType on Start screen tiles. I find it irritating but it doesn't matter because I spend < 1 minute per day on Start. But it does matter in Office and in IE. Like Gabe, I don't see the point of subpixel scrolling; for the little benefit in perceived smoothness *only when scrolling* we pay by giving up crisp font rendering *entirely*. The same goes for all these animations in Modern apps. Of course the animation system could try to be smart and render with ClearType when text doesn't move and without when animating. (I've heard rumors that another big OS vendor employs that technique successfully.) But I'd readily disable those animations entirely if I could get ClearType rendering back.

    A large fraction of all text drawn by Office and IE is black, gray or white on opaque background. All this text could benefit from ClearType, as it did in Office 2010 and Windows 7. Both Office and IE have full control over the graphic composition process; it should be possible (if difficult) to determine beforehand whether a particular glyph run will ever be rendered on a transparent background, and to switch ClearType on and off accordingly.

  29. JM says:

    Poor, perpetually abused ClearType. People hate it, people love it, but very rarely do people seem to be indifferent about it. Putting stumbling blocks like dynamic backgrounds and bitmap scaling in its way certainly doesn't help any.

    I think it's amusing that whenever people complain about the inclusion of ClearType, they usually complain of blurry fonts. And whenever people complain about the lack of ClearType, they usually complain of blurry fonts... The conclusion seems to be that the *existence* of ClearType (rather than any use of it) is the main cause of blurry fonts. Damned if you, damned if you don't!

    [Indeed, I can't tell from reading the uservoice link whether people are saying "Turn on ClearType to fix the fuzziness!" or "Turn off ClearType to fix the fuzziness!" I think it's a little of both. -Raymond]
  30. DebugErr says:

    Another prominent problem caused by this is drawing text on Aero Glass. You can only use DrawThemeTextEx which uses a different approach to render the text.

  31. dmw says:

    I agree that the Uservoice request is not ideally worded, but the demand is clear to me: "...DirectWrite must use subpixel antialiasing with checkbox is on", IOW, respect my system settings.

    The ClearType wizard has that checkbox called "Activate ClearType" on the first page which toggles between subpixel antialiasing and grayscale antialiasing. Modern UI apps, IE and Office 2013 ignore that setting and always render (parts of) their UI with grayscale antialiasing. The Uservoice request simply demands that this user setting be heeded by everyone.

    [As noted, this means that Modern UI apps couldn't use Direct Manipulation, which means that panning animations will be really slow and jerky since they will require a full render pass on the UI thread at each frame, instead of just moving a sprite. -Raymond]
  32. DebugErr says:

    @IanBoyd: Hah, that's a coincidence, I recently posted on your SO question you linked above with the glass rendering problems (which could be another nice article too, why solid rectangles drawn with GDI bug up), and now I meet you here again :)

  33. Vulpini says:

    @alegr1: 4k displays will make ClearType unnecessary *for the people who have them*. Unless you're proposing dropping support for lower resolutions entirely, or you want to pay for everyone's high-res display. And then there's the assumption of either high density or greater distance from the screen -- 4k on a 50" display is a lower PPI than 1920x1080 on 24".

  34. Joshua says:

    @xpclient: There aren't. That would have gotten me out of trouble ages ago.

  35. Jonas Hertzman says:

    The big issue and the reason why there are so much complaints here, is that we are not just talking about sub pixel antialiasing vs grey scale antialiasing. The new text rendering algorithm used by Metro apps, the new Internet Explorer and Office, have also started to disregard where on the pixel grid a letter is painted, and the shape of the letter.

    As an example, look for a text that has two l after each other and study how each letter is painted. Depending on font and size you will most likely see that an l is sometimes painted as a black line, and sometimes as a grey rectangle. The same error can also be seen on different parts of a single letters, the two vertical lines on a capital H might not be pained with equal thickness, the left one might be two pixels wide while the right one is only one pixel wide.

    This is what people complain about when they say text is "blurry" or "fuzzy", and since the old clear type rendering do not produce these graphical errors, we get these requests to "Return subpixel antialiasing to IE and ModernUI apps".

    I'd say grey scale antialiasing is OK, as long as all occurrences of the same letter are painted identically regardless of where in the text they occur, and as long as all lines that make up the letters are painted identically regardless of what letter they are part of.

  36. dmw says:

    @Jonas Hertzman: I think this is called "font hinting", and yes, I miss that too in Modern UI apps.

    WPF applications also have the bad habit of not using hinted fonts by default. Here is a screenshot which points out the difference:

    blogs.msdn.com/.../wpf-4-0-text-stack-improvements.aspx

  37. Rendering surface is just half the issue. The other half is ICC profile and font hinting. In passing, dodging or otherwise negotiating these pitfalls one has to deal with the abstract layer of interpretation too; i.e. would you do it like Adobe, Apple or Microsoft?

  38. Mark Sowul says:

    Users don't care about technical reasons -- at the end of the day, text rendering has been impaired for the sake of animation.  Do I use Word and Internet Explorer to look at animations, or read text?

    As an analog to "kernel-colored glasses" I'll call this "developer-colored classes"

  39. stickboy says:

    >  Both trade-offs are pretty expensive, and the cheaper alternative is usually simply to stop using color-aware ClearType.

    Sorry if I'm being dense, but how are application developers supposed to do that?

    [See the first linked article. -Raymond]
  40. dmw says:

    [As noted, this means that Modern UI apps couldn't use Direct Manipulation, which means that panning animations will be really slow and jerky since they will require a full render pass on the UI thread at each frame, instead of just moving a sprite. -Raymond]

    I am confident there are more options than only "Direct Manipulation" and "slow and jerky". I'll have to check whether scrolling in IE 11  on Windows 7 (= no Direct Manipulation) is slow and jerky, but I doubt it. And even Direct Manipulation isn't set in stone and could be improved for Windows 10. An additional flag to disable subpixel panning has already been suggested. (Note that subpixel panning is almost irrelevant anyway for Office and IE because typical PC screens have a horizontal subpixel layout and almost all scrolling on websites and in Word documents is vertical; it is only in Modern apps that horizontal scrolling is common.) Or Direct Manipulation could render two sprites, one with perfect text rendering and one for animating. And regarding the issue of not knowing the background you render on: the largest fraction of all text ends up being rendered on opaque background, so this case deserves special treatment or additional smarts. Perhaps the render stage which draws text to a buffer could enable ClearType if it also passes in the background color. Anyway, I'm sure you and your colleagues who are more familiar with the rendering process can come up with better ideas.

    It isn't fair to accuse you of "developer-colored glasses" - after all this is a technical blog, and most readers are here to learn about technical details and not about product politics. But I agree with the rest of Mark Sowul's sentiment: all the technical details are just an explanation, not an excuse. All the users can see is that font rendering was fine in Windows 7 and Office 2010, and that Windows 8 and Office 2013 break it for no apparent reason.

    [It is slow and jerky; that's why they switched to DirectManipulation. (Try scrolling while a heavy script is running.) DirectManipulation does not do any rendering. All it does is move sprites around. I guess you could have an 'integer translations only, if there is no scaling or rotation active' mode for DirectManipulation. -Raymond]
  41. Myria says:

    I've noticed that Windows 8.1, ClearType attempts to do sub-pixel anti-aliasing on text that is rendered by applications that don't support High DPI and are thus automatically scaled by Windows.  The result is awful.  ClearType ought to be smart and know that in processes that are in compatibility mode for High DPI, it should only do full-pixel anti-aliasing.

    [ClearType was correct at the time it was written. At the time ClearType was written, automatic DPI scaling did not exist. This is a case where advancements in one technology can cause older technologies to behave suboptimally. Do you want to take the compatibility risk of changing how ClearType works? And if so, you just created an unfunded mandate for the ClearType team. -Raymond]
  42. Marc K says:

    There's a lot of strong opinions regarding ClearType and font smoothing because things started getting forced on users.  With IE9 and later, there is no way to disable font smoothing.  Then there was WPF, which pushed the problem into 3rd party applicaiton.  Eventually WPF added the ability for an individual application to set the text options, but left the default at forced font smoothing.  This was a terrible solution because system settings are still ignored and application developers don't want to bother with the work.

    People would be less emotional about ClearType if the options that they set at the system level were honored.

  43. ender says:

    > Do you want to take the compatibility risk of changing how ClearType works?

    Since ClearType can be disabled at any time, those applications should work just fine if ClearType was disabled for them (and either plain anti-aliasing or nothing was used). IMHO that would be a lesser compatibility problem than scaling the window after rendering.

    [Consider an app that renders text into different-sized boxes depending on whether ClearType is enabled. If you silently ignored color ClearType requests, then the kerning will be different, and the text may overflow. -Raymond]
  44. Joshua says:

    [If you silently ignored color ClearType requests, then the kerning will be different, and the text may overflow. -Raymond]

    I was afraid that was going to be the case.

  45. ender says:

    > Consider an app that renders text into different-sized boxes depending on whether ClearType is enabled.

    But wouldn't the app see ClearType as disabled, so this wouldn't be a problem?

    [Many apps do "Get ClearType setting, change setting to X, create a font, restore ClearType setting" to create a font with a specific ClearType setting X. When you run these apps, your system ClearType settings will always be reset to disabled. Then you'd complain "Stupid Windows. Why does it keep resetting my ClearType settings?" -Raymond]
  46. ender says:

    > Many apps do "Get ClearType setting, change setting to X, create a font, restore ClearType setting"...

    Still, most apps don't do that, and lying about ClearType would only affect the default setting. If the app explicitly requests ClearType, it should still get it, but when it's running in scaled mode, the default could still be ClearType off.

    [I guess I wasn't clear. The problem isn't the app changing the setting. The problem is the app restoring the setting. Since we lied about whether ClearType is enabled, the app will think it's restoring ClearType to its original setting, but it's actually turning it off. So every time you run the app, ClearType gets turned off. -Raymond]

Comments are closed.

Skip to main content