WPF text renderer produces badly blurred text on small font sizes - by Pavel Minaev [MSFT]

Status : 

  By Design<br /><br />
		The product team believes this item works according to its intended design.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 380919 Comments
Status Closed Workarounds
Type Bug Repros 100
Opened 11/10/2008 4:10:12 AM
Access Restriction Public


WPF text renderer is different from GDI ClearType in that it does not snap lines in character glyphs to pixel columns. As claimed, this is to preserve the correct text proportions. However, the end result is that for on-screen text and relatively small font sizes (such as Tahoma 8pt - the default XP GUI font; and Segoe UI 9pt - the default Vista GUI font), the text rapidly loses contrast and looks extremely blurry. 

As a result, any WPF application that tries to look as a stock Windows desktop application (i.e., does not use non-standard or larger fonts) suffers from readability issues. A very good example of this is WPF property grid in XAML designer in VS2008+, and IntelliSense dropdowns in VS2010 CTP. The Expression suite tries to weasel out by using dark background and bright text color, which looks somewhat better, but still not good enough.

Note that the often-suggested (by Microsoft support people) "solution" to tweak WPF ClearType settings by editing the registry does not solve the problem. Recommendations to use different (non-system) font faces and/or sizes and text color cannot be taken seriously either - a stock desktop application should use the system UI text color, font family & size for UI controls, period. 

If WPF is to be useful for LOB and stock desktop applications, it should either allow to use the default system font renderer for text (on an opt-in basis), or, alternatively, provide some other means to ensure that on-screen text legibility is at least as good as GDI ClearType. 

Some relevant links to discussions, explanations etc, to indicate that this is a well-known issue that is very widely perceived as a serious problem:


Also, a Google search on "wpf blurry text" gives plenty of different hits, most of which are negative comments regarding the issue:


Sign in to post a comment.
Posted by ischilling on 3/31/2011 at 7:01 PM
Well, it seems like if the bug is back - whysoever.
Posted by Joshua25640735 on 8/30/2010 at 9:31 AM
It's even worse than one would guess for me. The assumptions used by even greyscale antialiasing are wrong for me.
Posted by davepl on 6/8/2010 at 1:12 PM
I've been using Visual Studio since it was MASM, and I'm uninstalling VS2010. First off, blurry fonts are just unacceptable. Even worse is blaming WPF (true or not), registry hacks, and so on.

It also won't let me use the same font I've been using since MS Mail 3, which is "MS Mail3.fon", another showstopper.

No sale.
Posted by Pavel Minaev [MSFT] on 3/11/2010 at 4:19 PM
To everyone who is tracking it, please have a look at the most recent updates (they did _not_ make it into VS2010 RC, so you haven't seen them live yet) - the difference for bright text on dark background is especially prominent:

Posted by UnderDogInc on 2/26/2010 at 12:55 PM
Please fix.

WPF is an amazing technology.

Font Rendering is an amazingly obvious base requirement.

If we must choose b/w WPF & good rendering....
Posted by Chipalo [MSFT] on 2/17/2010 at 2:43 PM
StevenC - WPF allows you to choose ClearType, Grayscale, or Aliased text rendering via the TextOptions.TextRenderingMode. We also respect thy ClearType system settings. VS has overridden this option ONLY FOR CONSOLS. Consolas is hinted to be used with ClearType so it looks extra bad if it is used without ClearType. If you disable ClearType in the system VS respect this for any other font.
Posted by GONeale83 on 2/14/2010 at 8:19 PM
Hi guys,

I have re-opened this under Visual Studio 2010 RC here.
Posted by Mauricio Scheffer on 2/12/2010 at 5:52 AM
While this was improved in .NET 4.0 RC, it's still blurry compared to VS2008. This issue should be reopened.
Posted by SvenC on 2/9/2010 at 4:56 AM
Still the same in VS2010 RC.

I am not sure if the reported issue was understood by Microsoft. We do not want an optimized ClearType or anti aliasing algorithm for displaying text. We want an option to *disable* any sort of ClearType, AntiAliasing or gray scaling of text.

Best would be to respect the users ClearType setting in Windows. That way all apps would display text in an identical way. Why would you think that a user disables ClearType in Windows and would want it when he runs any other app which happens to be written with WPF?
Posted by scorpion007 on 1/19/2010 at 8:28 PM
droid, I'm on Win XP SP3 and, while I have tuned my ClearType (as suggested by some MSFTies), it looked just as bad before I did.

My cleartype looked fine untuned (and tuned) in the OS, but always looks bad in VS 2010.
Posted by androidi on 1/15/2010 at 1:28 AM
scorption007: Do you get that with an install of Win7 where the ClearType tuning settings have not been touched and other (visual effects) settings are default too? I know that if the ClearType has been tuned then the tuned settings look fine in the OS but in WPF/VS it looks horrible.
Posted by scorpion007 on 1/12/2010 at 12:47 AM
Well, it's still not fixed as of Beta 2. See here: http://img706.imageshack.us/img706/8350/vs2010blurry.png
Posted by Pavel Minaev [MSFT] on 10/19/2009 at 12:13 PM

I'm not on WPF team, so you'll need to clarify that with them. Your best bet is to open a separate ticket for the issue you're seeing.

That said, I would be somewhat surprised if ClearType would work for rendering to bitmap. After all, ClearType is display-specific (consider RGB vs BGR displays, for example); and there's no telling as to what you might do with that bitmap after you render it. Even if it ends up on the screen, it can end up on a different display. Furthermore, if it has any alpha in it (or you apply effects to make it transparent), then ClearType subpixel antialiasing will be all wrong, since the border pixels will be blended with the background.
Posted by stormcrow_au on 9/30/2009 at 7:30 PM
Some further info: the introduced TextOptions.TextRenderingMode is functionally what we need, but we need to apply it to a RenderTargetBitmap. We're manually double-buffering because our testing has shown that rendering so much text directly to the screen is about an order of magnitude slower.
Posted by stormcrow_au on 9/30/2009 at 6:49 PM
Hey int19h,

We've got a blocking issue where ClearType is unavailable when using RenderTargetBitmap. I've checked out the wpf-4-0-text-stack-improvements.aspx article before - can you comment on whether ClearType is available rendering to RenderTargetBitmap using the Beta 2 bits?
Posted by Pavel Minaev [MSFT] on 9/1/2009 at 1:13 PM
You can see the screenshots of new WPF rendering here:

Posted by Pavel Minaev [MSFT] on 8/25/2009 at 9:23 AM
Some (kinda) updates for those who are tracking this. Since opening this bug, I have joined Visual Studio team in Microsoft, so working with the latest builds I get to see the fix firsthand :) and yes, guys, it really is a proper fix. It respects OS ClearType settings, and if that's turned on, smoothing is disabled completely - you get the same crisp/pixellated (depending on your taste) text that you see in any other Windows applications. And with ClearType enabled, smoothing is done in pretty much the same way as OS itself does it - I can't say if it's a pixel-for-pixel match, but the results definitely look very similar, at not at all worse.

Can't say when beta2 is going to be out, unfortunately, but rest assured that this problem will be gone there for sure. I'll ask around to see if we can get someone to blog a few screenshots demonstrating the fix before then.

- Pavel Minaev [MSFT]
Posted by Daniel Smith on 8/14/2009 at 4:28 AM
Thanks for posting that article keff85, really interesting read, hopefully that gives MSFT some additional ideas.

Does anyone know when Beta 2 is due out so we can take a look at the improvements first hand?

Here's a laugh folks - I've just been browsing http://windowsclient.net/getstarted/ and the "...superior content readability" under the WPF summary nearly made me spit out my tea! I can't believe they actually had the cheek to write that!
Posted by Keff85 on 8/2/2009 at 12:59 PM
I would like to introduce the work of Maxim Shemanarev - he came up with a better method for sub-pixel rendering, allowing for sharp fonts even at small sizes with Ideal Width Layout: http://antigrain.com/research/font_rasterization/
Posted by ljbreedt on 6/6/2009 at 2:49 AM
I would hope that Microsoft does not regard the rendering that presently forms a part of beta 1 (VS2010/NETFX4) as a "comparable" replacement.

VS2010 would be almost unusable for me if that is the case.
Posted by Oleksiy Gapotchenko on 5/30/2009 at 1:46 PM
> Has this been fixed in the just-released .NET Fx 4.0 Beta 1
No, it wasn't
Posted by Jan Kučera on 5/21/2009 at 9:20 AM
I really hope this compatible width layout will be optional only.
Posted by Maximilian Haru Raditya on 5/19/2009 at 10:33 PM
Has this been fixed in the just-released .NET Fx 4.0 Beta 1?
Posted by BlackWasp on 2/24/2009 at 8:55 AM
This problem is the sole reason why I cannot consider creating WPF and Silverlight applications for customers. Although the description of the problem of device-independant rendering is interesting, it is almost irrelevant to developers and users. Many users will simply not accept an application with such poor text quality.
Posted by Microsoft on 2/6/2009 at 12:32 PM
We are replacing WPF's text rendering stack in WPF 4.0, and this should allow you to render text with comparable sharpness to what you're used to with GDI. The reason the existing text stack in WPF looks blurrier than GDI's is that GDI text is typically rendered with Compatible Width Layout, whereas WPF's existing text stack always uses Ideal Width Layout. Compatible Width Layout snaps glyphs to pixel boundaries, Ideal Width does not, which is why WPF's text looks blurrier than GDI's. WPF's existing text stack also does not support use of the embedded bitmaps that are included in many fonts and are intended to be used when rendering at smaller sizes.

The new text stack in WPF 4.0 will allow Compatible Width Layout, and it will also support embedded font bitmaps. We believe this will solve all of our text blurriness issues.

-The WPF Graphics Team
Posted by ooDavid on 12/13/2008 at 5:33 PM
The issue is a show-stopper. It makes the whole WPF unusable in production environment and as such it should be treated as a blocking issue.
Posted by Pavel Minaev [MSFT] on 12/12/2008 at 12:06 AM
It looks like DirectWrite in Windows 7 will also use the same approach to font rendering:


Posted by Jason Webb on 12/1/2008 at 2:12 PM
Voted for it with 5 stars... It NEEDS to be fixed, however it only seems to happen with smaller font sizes, so it shouldn't be too hard to update with small tweaks, as larger sizes look great with WPF font smoothing.
Posted by Pavel Minaev [MSFT] on 11/26/2008 at 12:30 AM
> The display model targets next-generation display hardware that is supposed to address unified display model issues by acting more like high-resolution hardcopy devices, rather than todays display adapters.

That's all well and good, but WPF is released today, and applications that are written using it are being used on today's display hardware, not some abstract "next-gen". If it is designed for future hardware, then why it is marked as production-ready, and software is being written and released using it (such as VS10)?

That said, the only screen on which I can't see much difference in quality between WPF and native ClearType so far is 15" 1920x1200 of my T60p (though the difference is still noticeable). Eve when "designing for the future", should we seriously expect that this kind of DPI will be available on the desktop of an average user within 3-4 years?
Posted by Peter Zo on 11/23/2008 at 5:47 PM
Same here, it's blurry regardless of what font I use. I tried them all. People's eyes are different. Those at Microsoft need to understand this! How do you explain a color-blind person the difference between red and green? :(
Posted by Tony Tanzillo on 11/23/2008 at 12:08 PM
The display model targets next-generation display hardware that is supposed to address unified display model issues by acting more like high-resolution hardcopy devices, rather than todays display adapters.
Posted by Pavel Minaev [MSFT] on 11/16/2008 at 9:06 AM
I'll second that latest comment, too. Personally, I prefer GDI ClearType, but I think that the more important general principle here is this: if the OS has a configurable setting regarding text anti-aliasing, it should be used uniformly by all programs that render text, with _optionally_ overridable per-program settings where it makes sense (as in IE7 or MS Office 2007). By default, all stock UI elements should just pick system settings, as that's what the end user has full right to expect.
Posted by Petr Vones on 11/16/2008 at 3:24 AM
This issue prevents me from using the product at all.

I'm unable to read any text using any form of anti-aliasing. I can't stand both Win32 GDI ClearType and WPF text rendering. The only acceptable font rendering for me is Win32 GDI with ClearType turned off. If there is black color font on white color background I need it to be rendered by black or white color pixels exclusively. Any other color in between makes it blurry and hardly readable (reminds me old CRT monitors with badly adjusted convergence). I don't want to tune it, I want an option to TURN IT OFF at all. The same way like Windows XP or IE7 does.
Posted by Microsoft on 11/11/2008 at 9:15 PM
We were able to reproduce the issue you are seeing. We are escalating this issue to the product unit who works on that specific feature area. The product team will review this issue and make a decision on whether they will fix it or not for the next release
Posted by Pavel Minaev [MSFT] on 11/11/2008 at 10:44 AM
Actually, it doesn't seem to be a problem with the editor itself, if you pick the right font - I use Consolas 13pt, and for that, I don't notice the rendering difference between VS2008 and VS2010 CTP. The problem is in the IntelliSense dropdowns - they're also WPF, and they use some smallish font (not sure what it is, doesn't look like it's system font). And there the blurriness is really noticeable.
Posted by Microsoft on 11/11/2008 at 3:45 AM
Thank you for your feedback, We are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com/)
Posted by Avery Lee on 11/10/2008 at 7:26 PM
I'd agree -- subpixel positioning of text is a minus if it means that text hinting is disabled, and the loss of contrast is noticeable. This is going to be a serious problem with the VS2010 text editor.
Posted by Pavel Minaev [MSFT] on 11/10/2008 at 4:19 AM
More relevant links: