none
Blurry text in WPF - current status?

    Question

  • Hi,

     

    I was trying to find out if the blurry text I'm seeing in my WPF application could be due to something I'm doing wrong.

    But then I realized that other people's examples have it as well, and discovered several reported issues with blurry text rendering in WPF (all of them from some time ago) and I tried to find out whether a solution exists now. But I couldn't.

     

    So, I guess this is the right place to ask: has this issue with blurry text rendering in WPF been addressed by now? Or do we really need to live with it (and hopefully our customers too)?

     

    Although I noticed it right away, I never paid much attention to it because I thought "it's probably a setting somewhere", but so it seems not? Or has this changed?

     

    Here at home, I'm on an "old" analog 19" monitor (1280x1024), and I tried all combinations of "smooth edges of screen fonts". It also shows on the Vista-based machine at the office with a 24" LCD screen.

     

    What am I missing?

     

    Koen

     

    ----------

    System specs:

    CPU: AMD XP 2400+

    RAM memory: 1024 MB

    Graphics card: ASUS V9520 VS

    OS: Windows XP SP2

    DirectX: 9.0c

     

    Wednesday, January 09, 2008 4:30 PM

Answers

  • Displaying text at small sizes is a hard problem.  Speaking in broad generalizations, text rendering typically falls into two techniques:

     

    1) Distorting text characteristics to align to the pixel grid.
    This can involve adjusting glyph sizes, tweaking spacing between characters, shifting entire runs of characters, changing the glyph shape (either by manual hinting, or some automatic process), etc.  The positive effect is that the characters are crisp.  The negative effect is that a typeface will lose its distinctive look and that the overall size of a text run can be very inaccurate.  In general, it is very difficult to build a WYSIWYG (DPI-independent) system.  Text layout for flow documents can be very different depending on whether you are on a 96 DPI CRT or a 120 DPI laptop.

     

    2) Preserving the text characteristics on an idealized grid, and blending the results to the pixel grid.

    Basically you achieve an effect as if you rendered the text at some high resolution and scaled down to whatever your DPI happens to be.  The positive effect is that the text characteristics (shape, size, spacing, line length, etc) are much more accurate in the context of the other graphics in your application.  The negative effect is that the text is likely to be blurry because glyphs will effectively be drawn in the middle of pixels, and the only way to represent that is to blend all contributions to the pixel together.

     

    WPF attempts to bring the worlds of documents and rich UI together.  We believe deeply in a DPI-independent graphics API, as this gracefully straddles the variety of hardware available today, and likely to increase in the future.  Because of these design tenants, we chose to implement #2.

     

    To alleviate some of the negative effects of #2, WPF invested heavily in a new ClearType implementation that allowed us to start rendering glyphs in the middle of a pixel.  This allowed us to effectively increase the perceived resolution of our text rendering on LCD monitors.  While this improved the situation, it certainly did not solve it entirely.

     

    Worse, our ClearType rendering system must be disabled in some cases.  This forces us to use a basic grey-scale anti-aliasing, which looks much worse.

    http://arbel.net/blog/archive/2007/02/02/give-me-back-my-cleartype.aspx

     

    Of course, we also care deeply about our customers being successful.  It is clear that our text rendering is not clear enough in many scenarios.  Unfortunately, the other design considerations make solving this problem very difficult.  We are investigating our options, but we have not found any good solution yet.

     

    For the interested reader, here are some interesting links to browse:

    http://www.paulstovell.net/blog/index.php/wpf-why-is-my-text-so-blurry/

    http://fortes.com/2007/05/25/font-rendering-in-across-rich-platforms/

    http://www.codinghorror.com/blog/archives/000884.html

    http://www.joelonsoftware.com/items/2007/06/12.html

    http://antigrain.com/research/font_rasterization/index.html

    Friday, January 11, 2008 8:52 PM
  • We can't commit to having a solution until we're 100% sure it's going to ship in our final product.  We really don't want to get into a situation where we promise we'll fix something, and then at the last minute we discover that the fix causes huge show-stopping problems and we're forced to revert back to the non-fixed behavior after promising it'd be fixed.

     

    That having been said, the old canned response that we're "aware of customer concerns" does absolutely nothing to convey how we're prioritizing the issue or how long it will be until we ship a fix.

     

    So in relation to the specific problem of blurry text:  This has been a very high priority issue for us.  It's been discussed in multiple meetings with multiple levels of management, I've sat in developers' offices and squinted at prototyped fixes that made some cases better, others worse.  We haven't yet hit a solution that fixes the problem sufficently that we can ship it.

     

    Fixing this isn't easy, since the fonts are being rendered the way the original WPF text team intended for them to be rendered.  The behavior you're seeing is by design, the problem is that the designed behavior sacrifices contrast for the sake of positional accuracy.


    I explained more of the details of how fonts are rendered in my post here:

    https://forums.microsoft.com/msdn/showpost.aspx?postid=2463039&siteid=1&sb=0&d=1&at=7&ft=11&tf=0&pageid=1

     

    So where are we then?  We (the WPF team) considers this a very high priority issue.  We've prototyped changes to the rendering behavior, but so far none of them have been good enough that we could ship them.  It may well turn out that fixing the problem will require significant, fundamental changes to the way we render text, and if this is the case then the time required may push out the date when we do get it fixed.  We haven't yet found our magic bullet unfortunately.

     

    I hope that sheds some light on the issue.

     

    Thanks!

    David

    Friday, January 11, 2008 9:07 PM

All replies

  • Every communication from Microsoft has more or less said "f the designers" with no chance of even trying to fix the issue. In short: Microsoft does not view it as a bug, so I doubt it'll get fixed any time soon.
    Wednesday, January 09, 2008 5:34 PM
  • Are you sure MS doesn't view it as a bug?

    IMHO, it's not only a designers issue, but definitely a users issue: this text is just harder to read than what it used to be (instead of being better quality, which is what you'd expect from the newest technology).

    I can't really believe that such a big issue would be left untackled, especially given the otherwise overall high quality of the WPF architecture. This would mean a spoiler for all these efforts, no?

     

    Wednesday, January 09, 2008 5:50 PM
  • Trust me, I fully agree with you. However, when an issue is brought up as a showstopper for many people in March of 2006, and we're sitting here nearly two full years later, and Microsoft's standpoint is "our team is certainly aware of customer concerns and comments on this, but we cannot make any formal commitments yet on when and what improvements would be made." it's clear to me that Microsoft is dodging the subject.

    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=565101&SiteID=1
    Wednesday, January 09, 2008 6:27 PM
  • Displaying text at small sizes is a hard problem.  Speaking in broad generalizations, text rendering typically falls into two techniques:

     

    1) Distorting text characteristics to align to the pixel grid.
    This can involve adjusting glyph sizes, tweaking spacing between characters, shifting entire runs of characters, changing the glyph shape (either by manual hinting, or some automatic process), etc.  The positive effect is that the characters are crisp.  The negative effect is that a typeface will lose its distinctive look and that the overall size of a text run can be very inaccurate.  In general, it is very difficult to build a WYSIWYG (DPI-independent) system.  Text layout for flow documents can be very different depending on whether you are on a 96 DPI CRT or a 120 DPI laptop.

     

    2) Preserving the text characteristics on an idealized grid, and blending the results to the pixel grid.

    Basically you achieve an effect as if you rendered the text at some high resolution and scaled down to whatever your DPI happens to be.  The positive effect is that the text characteristics (shape, size, spacing, line length, etc) are much more accurate in the context of the other graphics in your application.  The negative effect is that the text is likely to be blurry because glyphs will effectively be drawn in the middle of pixels, and the only way to represent that is to blend all contributions to the pixel together.

     

    WPF attempts to bring the worlds of documents and rich UI together.  We believe deeply in a DPI-independent graphics API, as this gracefully straddles the variety of hardware available today, and likely to increase in the future.  Because of these design tenants, we chose to implement #2.

     

    To alleviate some of the negative effects of #2, WPF invested heavily in a new ClearType implementation that allowed us to start rendering glyphs in the middle of a pixel.  This allowed us to effectively increase the perceived resolution of our text rendering on LCD monitors.  While this improved the situation, it certainly did not solve it entirely.

     

    Worse, our ClearType rendering system must be disabled in some cases.  This forces us to use a basic grey-scale anti-aliasing, which looks much worse.

    http://arbel.net/blog/archive/2007/02/02/give-me-back-my-cleartype.aspx

     

    Of course, we also care deeply about our customers being successful.  It is clear that our text rendering is not clear enough in many scenarios.  Unfortunately, the other design considerations make solving this problem very difficult.  We are investigating our options, but we have not found any good solution yet.

     

    For the interested reader, here are some interesting links to browse:

    http://www.paulstovell.net/blog/index.php/wpf-why-is-my-text-so-blurry/

    http://fortes.com/2007/05/25/font-rendering-in-across-rich-platforms/

    http://www.codinghorror.com/blog/archives/000884.html

    http://www.joelonsoftware.com/items/2007/06/12.html

    http://antigrain.com/research/font_rasterization/index.html

    Friday, January 11, 2008 8:52 PM
  • We can't commit to having a solution until we're 100% sure it's going to ship in our final product.  We really don't want to get into a situation where we promise we'll fix something, and then at the last minute we discover that the fix causes huge show-stopping problems and we're forced to revert back to the non-fixed behavior after promising it'd be fixed.

     

    That having been said, the old canned response that we're "aware of customer concerns" does absolutely nothing to convey how we're prioritizing the issue or how long it will be until we ship a fix.

     

    So in relation to the specific problem of blurry text:  This has been a very high priority issue for us.  It's been discussed in multiple meetings with multiple levels of management, I've sat in developers' offices and squinted at prototyped fixes that made some cases better, others worse.  We haven't yet hit a solution that fixes the problem sufficently that we can ship it.

     

    Fixing this isn't easy, since the fonts are being rendered the way the original WPF text team intended for them to be rendered.  The behavior you're seeing is by design, the problem is that the designed behavior sacrifices contrast for the sake of positional accuracy.


    I explained more of the details of how fonts are rendered in my post here:

    https://forums.microsoft.com/msdn/showpost.aspx?postid=2463039&siteid=1&sb=0&d=1&at=7&ft=11&tf=0&pageid=1

     

    So where are we then?  We (the WPF team) considers this a very high priority issue.  We've prototyped changes to the rendering behavior, but so far none of them have been good enough that we could ship them.  It may well turn out that fixing the problem will require significant, fundamental changes to the way we render text, and if this is the case then the time required may push out the date when we do get it fixed.  We haven't yet found our magic bullet unfortunately.

     

    I hope that sheds some light on the issue.

     

    Thanks!

    David

    Friday, January 11, 2008 9:07 PM
  •  

    Try to check if Your blurry text or parent element doesn't use transformation.

    We are using Blend and sometimes, during design, Blend creates transformation.

     

    Dusan Kocurek

    http://diderhouse.spaces.live.com/blog/

    www.scurmdesk.com

    Friday, January 11, 2008 10:10 PM
  • You can imagine how people are losing faith. These issues were reported in early 2006. MS's been saying that "they're looking at a fix" all along.

     

    If it's such a high priority, how is it that it's been about at least 2 years since it's been a known issue? Did some senior person draw some graphs showing how we'll all be at 150dpi by 2007?

     

    (Heck, I have a 150 DPI monitor, I just can't run it at high DPI because even in Vista, too many things mess up -- it's a shame, 'cause things that DO work look so beautiful.)

     

    Anyways, I'm sure you've heard enough (do realise it's all user frustation -- WPF kicks *** in pretty much every other aspect). My question: is this something that's really being considered as a hotfix? Or is this only gonna happen with a major service point? I'm not sure if "final product" had any special meaning.

    Sunday, February 10, 2008 2:23 AM
  • I can't speak in absolutes, but if we had a solid solution and the schedule didn't match up with a major release then we would definitely consider releasing it in a hot fix.  This is a high-pri issue for us.


    Thanks!
    David

    Friday, February 22, 2008 1:09 AM
  •  

    So is this in the upcoming service pack for .NET 3.5 and so on?

    -Michael

    Friday, May 09, 2008 11:48 PM
  • I recently started a new project. I could have chosen WPF or WinForms for the project, and I picked WinForms. The main reason to stay with WinForms was blurry text in WPF. GUI is all about attention to detail, and my customers will never accept an "out ot focus" looking app. (Of course WinForms text is also a disaster, with no way to accurately measure text etc, and that's why I use interop to call Win32 API for all text.) Microsoft, usually in touch with the needs of the market and resposive to customers, just doesn't seem to get it in this case.

     

    By the way, I understand all about the technical issues as far as why text is blurry. I have written apps where what's on screen has to exactly match what is printed, so I know all about device-independent text rendering. But who cares about device independent rendering? Unless you are writing a word processor, a DTP app, a vector illustration program like Adobe Illustrator, or a print-ready-page viewer such as Acrobat, there is no need for device independent text. Business apps don't care about device-independent text. And that's the reason Win32 API and Win16 API before that have been so successful for business apps despite lack of device independent text.

     

    What business apps (as opposed to graphics apps) care about is readable text, not device independent text rendering. Device dependent text will always be more readable than device independent text. What WPF needs is a mode to switch between device independent and device dependent text. The first mode will be used by graphics and DTP apps that are willing to sacrifice a little bit of readability for accurate device-independent rendering. The second mode will be used by business apps that want the most readable text without any compromises, and don't care about device independence. Note that in business apps, dialogs are already prepared to handle varying string lengths (because of localization) so they are already prepared to handle variations in string metrics due to device dependent text rendering. Just make sure that in this second mode the metrics returned is device-dependent metrics.

    Friday, May 16, 2008 2:27 PM
  • Agreed; if a run has to be off by half a pixel, so be it. Check your priorities, please.

    Am I oversimplifying by thinking that the issue could be solved by snapping to pixels if the output resolution is under a certain amount (ie if it's a screen), or by at least offering us the option of turning it on or off?

    By the way, is it just me, or does the blurriness seem to depend on the graphics driver? Because I've gone through a few, and it seems to be extremely bad on some but not so much on others.

    Edit: looks like a fix is in order for WPF 3.5 SP1 along with a bunch of goodies, including custom bitmap effects on the GPU and hardware accelerated non-rectangular windows.
    • Edited by Rei Miyasaka Wednesday, June 18, 2008 7:22 AM Fix on the way
    Wednesday, June 18, 2008 3:43 AM
  • What I would really like to see is simply an option to tell WPF to render text the same way WinForms does.  After that, fixing the WPF rendering so it doesn't look bad would just be an added bonus.

    This issue is especially problematic when you have WPF controls hosted within WinForms controls, because you can see how much more blury the WPF text is side by side with the WinForms text.

    Even still, it's an issue when one application's text appears different than another application's text.  Just look at all the controversy that surrounded Apple's release of Saffari on Windows.  I don't want my WPF applications to go through that.
    Tuesday, June 24, 2008 10:19 PM
  • I'm not sure If I understood you correctly, but did you say that there is a way to call the Win32 API from WPF to render text? If you could share this method I would be forever grateful. I agree that the font rendering in WPF is horrible, making the product practically useless for data driven applications.
    Friday, July 11, 2008 2:40 AM
  • Rei Miyasaka said:

    Agreed; if a run has to be off by half a pixel, so be it. Check your priorities, please.

    Am I oversimplifying by thinking that the issue could be solved by snapping to pixels if the output resolution is under a certain amount (ie if it's a screen), or by at least offering us the option of turning it on or off?

    By the way, is it just me, or does the blurriness seem to depend on the graphics driver? Because I've gone through a few, and it seems to be extremely bad on some but not so much on others.

    Edit: looks like a fix is in order for WPF 3.5 SP1 along with a bunch of goodies, including custom bitmap effects on the GPU and hardware accelerated non-rectangular windows.



    I've checked out the 3.5 SP1 beta and i don't see any fixes for font rendering. There is a solution to help image rendering, but nothing about fonts. Am I missing something? If anyone finds a new solution available, please let me know.

    Levi
    Friday, July 11, 2008 11:20 PM
  • I have .NET 3.5 SP1 installed, and still:

    Three words. Horrible Font Rendering!  WPF font rendering is so stinkin blury (at least on XP SP2) that there is no way I can develop apps in it - it just strains the eyes too much.  And, as far as I can tell, there is no way to turn off the horrible anti-aliasing, and WPF ignores windows settings.  Showstopper for me, otherwise I might like it.

    The least Microsoft could do is provide a way to turn the antialiasing off!  Doesn't seem that should be so difficult now does it?


    Monday, September 08, 2008 5:21 PM
  • David Teitlebaum MSFT said:

    I can't speak in absolutes, but if we had a solid solution and the schedule didn't match up with a major release then we would definitely consider releasing it in a hot fix.  This is a high-pri issue for us.


    Thanks!
    David



    David Hi,

    I'll try to be as constructive as I can here.  It's been 2+ years since I and others originally brought this up.  If at all possible, we would like another update before the holidays please.

    The main point I want to make with this post is that the WPF team is severely over complicating matters.  Now, I'm sorry if the team made a critical design mistake which turned out to be very costly (device independent rendering - and didn't run anything by us, the community, before committing), but the solution is this:

    *** Forget device independent rendering as being an absolute requirement ***

    That's the entire problem.  You NEED to give us an option to lock in rendering to pixels.  It's that simple.  I (and all of the rest of us - well, the smart ones anyways) don't want to hear about how difficult device independent text rendering is.  We already know - monitors today aren't designed for it!

    Now, we'd rearchitect the WPF rendering engine outselves if you were open source or we had access to vast additional resources, but it's up to you for now.

    Do the right thing and get this fixed.  Implement what I've outlined above and it will pay off.  If you started this (and I recommended it before 2 years ago) when I originally proposed it, you'd be in much better position today.

    Wonder why Silverlight isn't taking off?  This is the reason.  Wonder why the real development community (myself and the rest of these posters) aren't in your corner any more?  I'm afraid, this is the reason.

    All that aside, I really do wish you the best of luck to you and thank you for your effort.  I hope someone with authority takes action before any more damage is inflicted on us or Microsoft.  Remember that the above solution is guaranteed to work, everyone wants it, it makes money, it can be made optional, there is extremely little downside (outside of engineering cost), and you need to start tomorrow.  Please forget about any solutions you might currently be working on.  It is highly likely that you're not working on the right thing.

    Please excuse the direct tone of this message.  If there is anything we can do to support you, please let us know.

    Thank you kindly,

    Sean
    Saturday, September 20, 2008 7:07 AM
  • I couldn't agree more.

    For God sake it's been over 2 years and the almighty MICROSOFT can't fix this?! If I were the PM for Silverlight I'd stop every other thing and ask the entire team to fix this, it's just too important, the web is made up of a lot of text and if this very text is hard to read (and dead ugly) then I wonder what your plans are.

    Also you guys better stop advertising this product and fix this VIRUS. If someone not loyal to Microsoft uses this once - he's never coming back. Don't you realize that the more you advertise this product the more customers you loose. Please update us on what you're currently doing regarding this.

    Thanks.
    Thursday, October 16, 2008 4:52 PM
  • OMG.  I'm so happy I found this thread.  A few months ago I started learning WPF and I thought I was losing my vision or something.  In all my test apps, I changed to the font size to 15 or higher because it looked blurry otherwise.  There is no way to use this technology in real applications unless the buttons are really huge.  This is a real blocker.
    Thursday, October 16, 2008 8:21 PM
  • This isn't a technical issue -- it's a managerial conflict confused with a design dilemma, spun as a technical issue.

    The situation as I see it is this:

       1. Some people are perfectly fine with WPF's rendering.
       2. Chances are that some higher-ups in the WPF team are fine with it, and so they don't want to change it.
       3. Some in the WPF team are concerned about device-independent rendering.
       4. The WPF team is spinning it as if it's an technical architectural issue as well as a design dilemma.

    But...

       1. Some people find WPF's text rendering to literally be an eyesore.
       3. Almost all Windows users are happy with standard ClearType.
       3. Adobe InDesign and Microsoft Word both snap glyphs to pixels, and their rendering is true enough to the actual state of the document and therefore to the printed document to satisfy even 30 year print industry veterans such as my dad.
       4. The issue is certainly not technical, considering other visual objects can be snapped to the grid just fine.

    Therefore, WPF should use standard ClearType and allow reverting to the current rendering method if it's really important at all.

    Dwayne Need [MSFT] said:

    In general, it is very difficult to build a WYSIWYG (DPI-independent) system.  Text layout for flow documents can be very different depending on whether you are on a 96 DPI CRT or a 120 DPI laptop.



    The current rendering method isn't WYSIWYG at all. In fact, it's worse than distorted layout.

    Even on a well-calibrated monitor, text that was intended to be 80% gray and prints at 80% gray, will appear as if it's 50-60% gray on screen because of the inherent loss of contrast.

    Friday, October 17, 2008 12:48 AM
  • Can someone from MSFT clarify the present status of this issue? For a "high priority" one, it looks like not much has been done about it since the last posts in January 2008 - and I don't mean the fix (I wish), but at least a clarification of what approaches are considered and when to expect anything new. Please don't sweep this under the rug!
    Monday, November 10, 2008 11:39 AM
  • Lending my voice to the request for clarification. It's a high priority issue and has been for two years now.

    I think that MSFT reps coming on here and saying they don't want to over promise a solution aren't realizing that there are many developers out there very turned off by WPF because it looks shoddy. Like someone very, very slightly tweaked the text just a hair out of focus. It looks unprofessional and while I am not a commercial developer, if I were, I wouldn't even consider WPF at this point without some guarantees that you guys are going to fix this issue.

    Would it be so hard to create a special brush or layer that you can guarantee will be opaque and say to developers, "If you want ClearType with custom visual chrome, draw it on this." Even an intermediate solution that required drawing text only on guaranteed opaque surfaces would go a long way to reassuring your developers that you hadn't lost touch with them... Which, after spending the past three days exploring my options for implementing the WPF Fluent UI element "RibbonWindow," shows me that MS clearly didn't test the code they were shipping.

    P.S.: For the love of god, will a MSFT employee download the WPF Office 2007 / Fluent UI Ribbon code, create a window with the RibbonWindow type as the root element, and tell me they would ship that in a commercial application after adding some text, some buttons and such. Try and come onto this site and tell us that you'd ship that.
    Tuesday, November 11, 2008 5:58 AM
  • Anpheus said:
    Would it be so hard to create a special brush or layer that you can guarantee will be opaque and say to developers, "If you want ClearType with custom visual chrome, draw it on this." Even an intermediate solution that required drawing text only on guaranteed opaque surfaces would go a long way to reassuring your developers that you hadn't lost touch with them... Which, after spending the past three days exploring my options for implementing the WPF Fluent UI element "RibbonWindow," shows me that MS clearly didn't test the code they were shipping.

    It would be very easy to do with a little bit of Interop. In fact we could probably brew up something basic in a couple hours.

    But I wouldn't encourage it. Complications would be plentiful. It wouldn't be a very good workaround. The problem needs to be fixed at its root.
    Tuesday, November 11, 2008 11:49 PM
  • At the PDC they announced that they will make use of the new DirectWrite technology in the next version of WPF, which by the way looks absolutely fantastic and seems to be the best technology for drawing text so far. Unfortunately it doesn't seem like they are committed to a short or mid-term solution for this problem.
    Wednesday, November 12, 2008 1:49 AM
  • Rei Miyasaka said:
    It would be very easy to do with a little bit of Interop. In fact we could probably brew up something basic in a couple hours.

    But I wouldn't encourage it. Complications would be plentiful. It wouldn't be a very good workaround. The problem needs to be fixed at its root.


    Could you please brew up something basic that gives me tooltips that don't look like they went through a Guassian Blur before being rendered? Could you give me pop-up menus that don't look obscene? Even if you only gave me a single method of -guaranteeing- ClearType, I could make my application look infinitely better and more professional.

    You guys need to understand how important this is, I'm going to ask one more time:

    Would Microsoft ship a business application built using WPF with their Fluent UI "RibbonWindow" as the document root?

    Simple question, but it strikes right to the heart of the issue. Would Microsoft ship something that, with the standard templates, is unusably blurry and difficult to read?
    Wednesday, November 12, 2008 7:07 AM
  • using System; 
    using System.Windows; 
    using System.Windows.Controls; 
    using System.Windows.Media; 
    using System.Windows.Media.Imaging; 
    using System.Drawing; 
     
    namespace WpfFormsTextRendering 
        public class CustomTextBlock : Control 
        { 
            static CustomTextBlock() 
            { 
                DefaultStyleKeyProperty.OverrideMetadata(typeof(CustomTextBlock), new FrameworkPropertyMetadata(typeof(CustomTextBlock))); 
            } 
     
            public CustomTextBlock() 
            { 
                this.SnapsToDevicePixels = true
            } 
     
            public string Text 
            { 
                get { return (string)GetValue(TextProperty); } 
                set { SetValue(TextProperty, value); } 
            } 
            // Using a DependencyProperty as the backing store for Text.  This enables animation, styling, binding, etc... 
            public static readonly DependencyProperty TextProperty = 
                DependencyProperty.Register("Text"typeof(string), typeof(CustomTextBlock), new UIPropertyMetadata(OnTextChanged)); 
     
            static void OnTextChanged(object sender, DependencyPropertyChangedEventArgs e) 
            { 
                (sender as CustomTextBlock).InvalidateVisual(); 
            } 
     
            System.Drawing.Size textSize; 
            Bitmap bitmap; 
     
            protected override System.Windows.Size MeasureOverride(System.Windows.Size constraint) 
            { 
                //TODO: implement with constraint in consideration 
                //TODO: convert this.FontFamily and this.FontStyle to use for this constructor 
                Font font = new Font("Arial", (float)this.FontSize); 
     
                //TODO: measure more robustly http://www.codeproject.com/KB/graphics/TextOnABitmap.aspx 
                textSize = 
                    System.Windows.Forms.TextRenderer.MeasureText(Text, 
                    font, 
                    new System.Drawing.Size((int)this.ActualWidth, (int)this.ActualHeight)); 
     
                bitmap = new Bitmap(textSize.Width, textSize.Height, System.Drawing.Imaging.PixelFormat.Format32bppArgb); 
     
                return new System.Windows.Size(textSize.Width, textSize.Height); 
            } 
     
            protected override void OnRender(DrawingContext drawingContext) 
            { 
                base.OnRender(drawingContext); 
                //TODO: convert this.FontFamily and this.FontStyle to use for this constructor 
                Font font = new Font("Arial", (float)this.FontSize); 
     
                //TODO: dependency property to use for the background, or make Background work 
                System.Drawing.Color bg = System.Drawing.Color.White; 
     
                using (Graphics g = Graphics.FromImage(bitmap)) 
                { 
                    g.SmoothingMode = System.Drawing.Drawing2D.SmoothingMode.AntiAlias; 
                    g.TextRenderingHint = System.Drawing.Text.TextRenderingHint.ClearTypeGridFit; 
                    g.Clear(bg); 
     
                    System.Drawing.Color fg; 
                    if(this.Foreground is SolidColorBrush) 
                    { 
                        SolidColorBrush scb = this.Foreground as SolidColorBrush; 
                        fg = System.Drawing.Color.FromArgb(scb.Color.A, scb.Color.R, 
                            scb.Color.G, scb.Color.B); 
                    } 
                    else 
                        fg = System.Drawing.Color.Black; 
     
                    System.Windows.Forms.TextRenderer.DrawText(g, Text, font, new System.Drawing.Point(0, 0), fg, bg); 
                } 
                //TODO: make this optional using a dependency property
                bitmap.MakeTransparent(bg);
                System.Windows.Media.ImageSource img = System.Windows.Interop.Imaging.CreateBitmapSourceFromHBitmap(bitmap.GetHbitmap(), IntPtr.Zero, Int32Rect.Empty , BitmapSizeOptions.FromEmptyOptions()); 
                drawingContext.DrawImage(img, new Rect(0, 0, textSize.Width, textSize.Height)); 
            } 
        } 
     

    Fonts and backgrounds are hard-coded, as are styles. For some reason, when I set the Control.Background property, it doesn't render the text -- you'll either need to figure out why, or make another dependency property for this purpose.

    Note that ClearType requires knowledge of the background color; otherwise you get artefacts. That means you can't have any high contrast gradients in the background.

    Performance is likely dismal, and there just isn't as much flexibility as there is with TextBlock. It also doesn't support the WPF document format, only raw text with specific fonts.


    DirectWrite either better be made available for Vista (and XP), or they better be working on a fix for WPF's wretched text rendering.

    The WPF team would be a bunch of idiots to say that this is such "a very high priority issue" that we all need to make our customers switch to Windows 7. It would just be pure bad business.

    Seriously, Microsoft, quit dodging the problem and answer us.
    • Edited by Rei Miyasaka Thursday, November 13, 2008 4:06 AM
    Thursday, November 13, 2008 4:03 AM
  • hi,
    i'm not very happy with this but i have to agree with almost everyone here. i started some time ago, after sp1, with some simple wpf data applications ( on vista and xp sp3 machines ) but there is no way to put my users to support this eye strain ( included myself ).
    for normal data applications this font problem is a killer despite nice graphical user interface and simplified ( so far ) programming.
    for now i have to return to windows forms to write applications for my firm but i hope microsoft wpf team will resolve the problem ( old ways or new ones ).
    until then ...
    Saturday, November 15, 2008 12:55 PM
  • I'd just like to add my sentiments on the issue. I don't need pixel perfect accuracy. I certainly don't need pixel perfect accuracy on simple UI elements. There's no excuse for having blurry buttons and dropdowns and the like. Even on a drawing canvas, a half pixel nudge one way or the other just doesn't matter. A full pixel is unlikely to matter even in a vector drawing program. Forget about pixel perfect accuracy. No one wants it at the cost it demands. WPF will never be adopted in its current state.
    Sunday, November 16, 2008 5:28 PM
  • This issue has been raised in several places already. To centralise things a bit, I have created a bug report on Microsoft Connect:


    If this issue concerns you, please come there and vote. Hopefully it will help to attract more attention to this problem from Microsoft, and facilitate a quicker resolution.
    Monday, November 17, 2008 10:43 AM
  • Does anyone know if there has been any progress on this ? I have started on my first WPF application and realise now that this issue is so significant that I cant expect anyone to use my application in this condition.

    I need to make a call whether to keep developing on WPF and hoping that this will be fixed within the next couple or months or revert back to Windows forms. If anyone know what the current position is and if a patch can be expected, it would be appreciated.

    Thanks

    Niclas
    Saturday, November 29, 2008 4:18 PM
  • Even on a well-calibrated monitor, text that was intended to be 80% gray and prints at 80% gray, will appear as if it's 50-60% gray on screen because of the inherent loss of contrast.

    That's definitely worth pointing out. There's something obviously and tragically wrong with the conversion to and from gamma and linear space when compositing text. The contrast issue is one part of it. Another way to see it clearly is to render black-on-white beside white-on-black text. The white-on-black text practically disappears. If I had to guess at the most glaring problem in the current implementation, I'd guess that text composition is being performed by blending in sRGB space instead of linear space (blending raw sRGB bytes, rather than converting to linear space, blending, and converting back to sRGB space).

    The way to solve gamma/linear conversion is to use Byte[256][256] lookup tables to convert to and from gamma space when compositing. Yes, they're big tables, but who's going to miss a couple of hundred kbytes of memory these days? The solution is still very approximate in close-to-black values, but the quality difference is night-and-day. Peformance is perfectly good, and the compositing code is trivial to implement in GPU, or in non-GPU code. And it's even decently robust when dealing with color-correction (with independent lookup tables for each RGB component).

    It would also be nice to see 8x8 supersampling resurrected for small text, and transformed text. GDI+ text rendering was beautiful with all quality options maxed out. I don't understand why a Typography quality option can't be added that produces performance-be-damned highest-possible-quality text rendering (which invariably turns out not to be that bad from a performance point of view). The current solution I use -- rendering quality-critical text in bitmaps using a bitmap editing package, like photoshop, or fireworks -- is really very tedious, and I know I'm going to regret it if high-DPI displays ever catch on. I wonder whether you can't get the bitmap guys and the font guys together. Bitmaps seem to composite spectacularly well.


    Saturday, November 29, 2008 7:02 PM
  • NicAnon said:

    Does anyone know if there has been any progress on this ? I have started on my first WPF application and realise now that this issue is so significant that I cant expect anyone to use my application in this condition.

    I need to make a call whether to keep developing on WPF and hoping that this will be fixed within the next couple or months or revert back to Windows forms. If anyone know what the current position is and if a patch can be expected, it would be appreciated.

    Thanks

    Niclas


    The most recent word on the matter from Microsoft was from Brian Harry of VSTS fame:

    "We know about the WPF font fuzziness issue and are working on it.  Hopefully we'll have a fix for the Beta."

    I guess this is good news, though I'll reserve the cheers until I see the result of the fix with my own eyes. Also, this was stated on the blog, and not e.g. here or in reply to Connect ticket, so I  guess you could say it's rather unofficial.

    Tuesday, December 02, 2008 7:05 AM
  • I wouldn't hold my breath.

    First we were told there might be a hotfix, then we were told it might be fixed in the next version, then they just down right abandoned the issue on Vista and XP and went straight to focusing their efforts on DirectWrite for Windows 7.

    Honestly I don't think I've ever seen Microsoft be this neglectful in a long time. There's clearly some sort of managerial conflict of interest.


    Microsoft should be worried about the fact that there isn't much real criticism regarding the issue despite its magnitude. It means that:
    1. people at Microsoft don't realize how bad the problem really is.
    2. people think WPF sucks and looks horrible, even if they can't pinpoint why.
    3. people stop caring.

    Tuesday, December 02, 2008 10:13 AM
  • Just to bump this thread and see if anyone have an update on this (Microsoft perhaps ?)

    Regards

    Niclas
    Monday, January 12, 2009 9:05 PM
  • We will improve the Cleartype text quality in the .net 4 time frame; i.e. in our next major release. This was also mentioned in Scott Guthrie's talk at PDC (http://channel9.msdn.com/pdc2008/KYN02/, skip to minute 86). We are making these improvements across all the operating systems that WPF supports today (XP, Vista) and Windows 7.

    One of the previous posts also mentions the quality of text in ToolTips, Menus, etc. All those controls use layered windows which technically could be translucent. WPF cannot render Cleartype text onto translucent pixels and therefore switches back to anti-aliased rendering which does not look as good as Cleartype text rendering in WPF. In .net 4 we will give you a flag to re-enable Cleartype. You need to guarantee though that the content behind the text is opaque, otherwise it will look wrong.



    • Proposed as answer by Jon Watte Monday, February 02, 2009 10:04 PM
    Tuesday, January 13, 2009 2:55 AM
  •  Thanks for the reply, are these improvements to be seen in the current beta release of VS 2010 ?

    Regards

    Niclas
    Tuesday, January 13, 2009 10:37 AM
  • We are in the process of figuring out if it will make the build snap or not. So I really cannot say.
    Wednesday, January 14, 2009 1:41 AM
  • deja vu?

    Windows' Presentation's (still) Fuzzy 
    Wednesday, January 14, 2009 2:23 AM
  • I'd like to share a few things I figured out that might cause blurry text and UI elements.
    • Fractional position and size
    • Center HorizontalAlignment / VerticalAlignment
    • Automatic resizing by sibling elements. This last one was very hard to figure out in my experience. I was using a tabcontrol. For some reason adding a particular tabItem makes OTHER tabItems blurry (header & content), even the tabcontrol border visibly shifts depending on the active tab. It turns out, the offending tab is slightly larger then the rest, and whenever it is rendered as inactive it shifts the whole tabControl by a fraction of a pixel. So the fix was to set all tabs to the same fixed width and height. And finally my app goes back from very blurry to WPF standard blurry :).
    Monday, January 26, 2009 5:53 AM
  • I don't want Anti-aliased. I don't want cleartype. I want good old old-fashioned hinted TrueType fonts -- it would look a lot better than the current smear, that can't do an "l," an "i" or a "1" correctly. While Windows Media Center doesn't care, because every font is 32 points or bigger, nobody can ship a real desktop app on the current look.


    XNA/DirectX MVP 2006-present
    Monday, February 02, 2009 10:05 PM
  • I understand that it is not possible to optimize for perfect sub-pixel placement/size and clarity at the same time, but why not give the designer the choice on a case by case basis, just like what is available with SnapsToDevicePixels?

    In most cases, I would happily give up per-pixel placement accuracy for text that doesn't give me a headache, and scrolling text that isn't nausea-inducing.
    Tuesday, February 03, 2009 12:18 AM
  • I agree with Mike Oliphant. There are cases where text clarity vs text positioning is 99% vs 1% in importance (this is the case with all-text desktop applications) and there are cases where the opposite is true (all graphics mobile applications). But since 80% of the developers are desktop developers, the default should be for text clarity and if you wanted the positioning, it should be provided as an optional feature that you turn on.
    Tuesday, February 03, 2009 11:20 AM
  • Well this is only a work around really but avoid using Segoe UI and use Calibri instead. It renders much clearer and is somewhat similar, although you will have to increase by about a pt size to make it look equal to other fonts.
    Tuesday, February 03, 2009 6:59 PM
  • If I want to pay money to Ascender to make sure that everyone gets Calibri on their machine when installing my app, that might be an option. But I don't (and I shouldn't).

    Here are two screen shots. Guess which one is WPF, and which one is Win32? (Hint: "l" and "i" in "File" or "Select All" will give it away)


    screen shot of bad wpf menu font  screen shot of good Win32 menu font

    XNA/DirectX MVP 2006-present
    Tuesday, February 03, 2009 8:15 PM
  • Alright guys, here are some good news at last. My MS Connect ticket has got a response. I'll just cite is here in full:

    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.

    Thanks!
    -The WPF Graphics Team


    Yay! 

    Friday, February 06, 2009 8:38 PM
  • Nice, can't wait.

    Hopefully a good chunk of the existing apps will migrate to 4.0.
    Friday, February 06, 2009 11:46 PM
  • I've seen that aplying a Bitmap Effect (lets say a Drop Shadow) to the LayoutRoot grid of a Usercontrol, all fonts inside appear a lot more  blurry (f.ex. in a Listbox).
    I'll better quit all bmp effects.


    Saturday, February 07, 2009 1:29 AM
  • That is fantastic news. If only that had been the case in 3.5 it would have been perfect :-)

    XNA/DirectX MVP 2006-present
    Saturday, February 07, 2009 6:21 PM
  • I really hope this is fixed in 4.0 as promised! :)
    Windows XP MCP
    Sunday, February 22, 2009 12:33 AM
  • Are there any good (technical I assume ?) reasons why this fix can not be released for 3.5 ahead of 4.0, which i'm led to believe is some time away ?  Would also be interesting to get a feeeling for time scales around when this fix will make it into the VS2010 beta cycle. MS Comment ?

    Cheers

    Niclas

    Sunday, February 22, 2009 8:26 AM
  • Will the fix apply to Silverlight also?
    Tuesday, February 24, 2009 5:00 PM
  • OH YEAH!
    Tuesday, February 24, 2009 9:20 PM
  • Yeah, will it be fixed in Silverlight?
    Sunday, March 01, 2009 5:27 AM
  • Does anyone have any news about this? This bug has been holding me back from using WPF...
    Thursday, May 14, 2009 1:43 PM
  • I guess you will have to download the VS 2010 and .NET 4.0 CTP and try it yourself to find out whether it's fixed yet.
    Personally, I just gave up on WPF. Too much complication for not enough benefit -- it's an over-designed and under-delivered API IMO.

    XNA/DirectX MVP 2006-present
    Thursday, May 14, 2009 5:03 PM
  • I dont want to get into a "WPF vs other platforms" argument but I disagree, I love WPF. Sure its still in its infancy so it isnt perfect but I create all of my apps in WPF now, I wouldnt dream of going 'back' to winforms unless there was a very good reason.

    Having said all of that, this blurry text thing needs fixing asap. I'm thinking about downloading the VS 2010 CTP but from what I have heard it isnt much different to VS 2008 and I've seen screenshots of a much more recent version of it that look a lot more promising so I might just wait for the next BETA to come out...
    Windows XP MCP
    Thursday, May 14, 2009 5:42 PM
  • This is the only full-sized screenshot of Visual Studio 2010 that I could find. Are there any more out there? I'm curious to see if the font rendering is fixed yet.

    As for WPF, I believe that the majority of concepts are so good that it would be a shame not to use it.

    That said, the implementation is honestly quite awful in a lot of ways. Sadly, Silverlight's implementation of XAML is better in some areas and even worse in others (why is everything sealed?!).

    There's a long road ahead for WPF and Silverlight, but I think the best thing for the industry in the long run is to be both brutally honest and supportive.
    Thursday, May 14, 2009 5:56 PM
  • This is one of the ones I was referring to: http://www.onedotnetway.com/wp-content/uploads/2008/11/image3.png
    The main shell of VS 2010 is written in WPF too apparently :)
    Windows XP MCP
    Thursday, May 14, 2009 6:00 PM
  • I think WPF did the wrong thing with dependency properties. I have used a very similar construct in C++ for a long time, and the extra steps you need to go through for each property and each binding really start weighing you down pretty quickly. In C++, templates, macros and member objects with operator overloading can help a lot, but we don't have that expressive power in C#.

    Given that WPF requires a new .NET runtime anyway, I believe they would have been much better implemented as a form of native properties in the language. Instead of separate dependency properties as objects in a hash table, optionally make each native C# property listenable (such that you can subscribe to change notifications, and signal change separately from set, as well). Similarly, make the default behavior of properties be calculate-on-read with caching. Finally, make each property delegatable. With those additions to the property system, and then using those improvements throughput the WPF implementation, many common tasks would be a lot simpler, and a lot of non-WPF, non-GUI code could use the same patterns, too.

    You'd need a few new keywords: "invalidate," "derive," "source," "storage" and "dirty".

      public int MyProp {
        get; // default implementation, uses internal backing storage
        set; // default implementation, uses internal backing storage, and calls "invalidate" if present
        invalidate;  // default implementation of subscription; mark "dirty" and then notify listener delegates
        derive; // default implementation of finding the source value and returning that, or if null, returning backing value
        source; // default implementation of chaining (delegation), will by default subscribe/unsubscribe as well
        dirty; // boolean keeping track of whether derive has been called since invalidated
        event; // event used when dependents want to listen/subscribe to invalidation
      }
      // "storage" can be used inside the property to refer to the internal backing storage.
      // "event" can be used inside the property to refer to the implicit subscriber event
      // "dirty" can be used inside the property to refer to the dirty state of the property

    You'd want some way to get meta-info about the property, instead of the property value. This might be a new operator (say, a "colon" operator) for example, or it might be decorated names (a la "get_MyProp").

    So, a property that returns Math.Sin(GlobalTime) and is not settable could be implemented as:

      public float SinProp {
        SinProp() { invalidate += GlobalTime.event; }
        get;
        invalidate;
        derive { storage = Math.Sin(GlobalTime); }
        dirty;
        event;
      }

    This would not be bindable, because it doesn't declare "source".

    If you assign to "source," you'd automatically bind the property to the output of something else, and automatically subscribe to that something else's event. Note: the event passes no arguments; the handler just sets the "dirty" bit and forwards to dependent listeners. You don't care about the value of the source until such time as someone asks you for your value and your "dirty" bit is set. Then you calculate it and set dirty to false (which is implemented internally by calling derive).
    An alternative implementation of SinProp would be something like:

      public float SinProp {
        SinProp() { source = GlobalTime; }
        get;
        invalidate;
        derive { storage = Math.Sin(source); }
        dirty;
        event;
      }

    This would allow you to re-define the source of the timing information if you wanted.

    Note that you can accomplish most of this in C++ using templates and class member instances. In C#, the amount of typing is quite terrible, and the performance suffers because of the hash table dispatch necessary for almost any dependency property operation.

    Now, this is not perfect. What would happen if you make "invalidate" virtual, for example, I have no idea about. Also, overloading some existing keywords (like "event") seems attractive, and you could *almost* use "value," except for the ambiguity in the set{} handler. Finally, advanced properties will want multiple inputs, and may even want multiple outputs. At that point, you want to derive from some interface, but perhaps still use some built-in support for the common patterns. I assume the Binding class would be an instance of that interface, for example.

    The amount of manual skullduggery involved in building anything real in WPF is quite annoying, and the risk of going out-of-sync because of all the different pieces of code that are scattered in the file and need to sync up is quite real. Especially after having done the same thing in C++ with 1/10th the typing of what's currently required in WPF, I'm really disappointed with the way they've chosen to implement it currently.


    XNA/DirectX MVP 2006-present
    Thursday, May 14, 2009 8:21 PM
  • I think we are going very off topic here but just a quick question, are you talking about native C++ or C++ that requires the .NET runtime or CLR or whatever its called? The reason I ask is because whenever I have tried my hand at C++ before I have never been able to make anything other than a console application (ie no forms or GUI to speak of) without using the .NET framework and in my opinion the main advantage of using C++ over VB or C# is that it doesnt require a large framework installation prior to users being able to run your code (maybe im missing something). I wouldnt mind giving C++ another try if there is a way I can create decent looking GUIs without having to have the .NET framework / CLR as a prerequisite
    Windows XP MCP
    Thursday, May 14, 2009 9:31 PM
  • Jon,

    I can't help but agree aside from the implementation details -- dependency properties or something similar should really have been a BCL and/or language and/or CLR feature; I've asked about this in the past as well.

    Alas, programmer aesthetics isn't as important as end-user aesthetics, and yeah, we're getting way off-topic :)
    Thursday, May 14, 2009 9:44 PM
  • When I'm talking about C++, I'm talking about native, hard-core, Win32-style C++ (or even a GUI rendered through Direct3D for graphics acceleration). I have not had a problem developing in that language, I guess because I learned C back in 1985 on a VAX/11 :-)
    If the user doesn't have .NET framework 3.5, the download/install required for a new application that uses that framework is pretty large. Meanwhile, all users always have Win32 installed (on Windows, that is :-). However, if you link with something like MFC, then that sizes the installation up a bit. Anyway, I don't think that's a big issue one way or the other.

    What IS a big issue is that developing real, input-heavy applications in WPF is about as enjoyable as writing device drivers in COBOL. And gives you a result with about the same amount of credibility -- the blurry text being just the (very visible) tip of the iceberg.
    XNA/DirectX MVP 2006-present
    Friday, May 15, 2009 6:59 PM
  • It seems that VS2010 and .NET 4.0 Beta 1 is out to MSDN subscribers...

    If anyone around here has access to such a subscription, please let us know if anything has been done about the blurry text issue. Since the whole new VS interface is built around WPF, I really hope so...
    Tuesday, May 19, 2009 1:52 AM
  • Yeah if anyone's got it then that would be good to know. I assume the BETA comes out fairly soon for the public then?

    Thats one thing I dont understand though, why dont Microsoft's WPF products have blurry text. I mean some parts of the Vista interface are supposedly WPF and I think Blend was made in WPF if I remember rightly. So why dont we see blurry text in those :S
    Windows XP MCP
    Tuesday, May 19, 2009 7:50 AM
  • I downloaded and installed the beta on two boxes yesterday and, unfortunately, the "fuzzy text" issue exists on both.  It's significantly better than most WPF applications, but still apparent (mostly, text just looks bolder).

    I took some comparison screen shots (http://www.timgthomas.com/Misc/VSWPFText.jpg); the top snippet is from Visual Studio 2010 and the bottom, 2008.  Both IDEs are using 8-point Consolas (my apologies for the odd colors; I didn't have time to revert back to the Visual Studio defaults).

    Tuesday, May 19, 2009 3:00 PM
  • TGThomas - are you just referring to the text within the Visual Studio IDE? because I dont think thats what everyone else is referring to (or at least I'm not). I'm referring to the text within WPF applications you have made when you actually run the application.


    Windows XP MCP
    Tuesday, May 19, 2009 3:19 PM
  • As the text editor inside VS2010 is written in WPF, it's essentially the same thing.  That said, the text rendering has been considerably improved for the text editor, but the menus still show some signs of the standard blurriness.  Additionally, if you need actual WPF applications to compare, I've created simple ones (screen shot ) in both 2008 (left) and 2010 (right); the anti-aliasing problems are identical in both.
    Tuesday, May 19, 2009 3:39 PM
  • Damn, the rendering still sucks...

    The one on the text editor doesn't look that bad though.
    Tuesday, May 19, 2009 3:51 PM
  • Here is the story:
    There are some substantial font quality improvements coming in WPF 4 as part of Beta2 that improve text quality crispness.  These aren’t in Beta1, and the editor text will appear fuzzier than it should at lower DPI resolutions.  Beta2 will have the same text editor crispness as VS08

    Thanks, Rob Relyea
    WPF/XAML Team
    http://robrelyea.com/blog

    Tuesday, May 19, 2009 4:04 PM
    Moderator
  • To elaborate on this a bit:

    The current plan is to ship WPF 4.0 Beta 2 with a vastly improved text rendering stack which will allow applications to set many more text rendering parameters than with previous versions of WPF.  The most important from the sake of text clarity/sharpness is the ability to snap glyph positions to pixel boundaries.  Most GDI text is rendered in this way, as GDI is a pixel-based rendering system (as opposed to WPF, which is a DPI-independent, vector-based system) which is why GDI text looks so shap.  When this glyph layout mode is selected in WPF, the rendered text should look nearly identical to GDI-rendered text.  The current plan is for this to be an opt-in feature, as changing low-level text formating mechanisms could break existing applications.  Setting this glyph layout mode on your whole application or on any subtree in your scenegraph should be a simple matter of setting an attached property on the parent of the subtree.

    David
    Tuesday, May 19, 2009 8:29 PM
  • This is because we default to turning off cleartype when rendering text into intermediate render targets, because the cleartype rendernig algorithm only looks correct when rendered to an opaque surface (because cleartype effectively triples the horizontal resolution of your display, and there is only one alpha channel per pixel on any normal render target, vs. the three alpha channels per pixel that would be required to render cleartype in an alpha-agnostic manner).

    We are adding a feature in WPF 4.0 called CleartypeHint that will allow you to override this behavior and force WPF to render with cleartype into intermediate render targets.  You should only use this when you know your IRT will be opaque.  It is useful when you want to use cleartype with ShaderEffects, in Layered Windows, and in any other situation that would otherwise turn off cleartype.

    David
    Tuesday, May 19, 2009 8:38 PM
  • Yes, we had to replace the whole text rendering stack to fix this problem.  It's not something we can just graft on to 3.5 unfortunately.

    David
    Tuesday, May 19, 2009 8:39 PM
  • To elaborate on this a bit:

    The current plan is for this to be an opt-in feature, as changing low-level text formating mechanisms could break existing applications.

    David
    David, Rob, thanks for the explanation.

    So existing applications will have to be upgraded to WPF 4.0 in order to take advantage of the pixel snapping, correct?

    If you don't mind me asking a slightly tangential (but still potentially relevant) question, will there be many breaking changes to fix the design/implementation problems in 3.5, or is the policy still to avoid breaking changes?
    Tuesday, May 19, 2009 8:48 PM
  • Yes, in general apps will have to be (re)compiled as WPF 4.0 applications in order to get clear text.

    Regarding your second question, I can't give you a real answer without specifics, but in general we've been directed to keep breaking changes to an absolute minimum for this release.

    David
    Tuesday, May 19, 2009 11:41 PM
  • Shucks, I heard that .NET 4.0 would run older assemblies on the 2.0/3.0/3.5 runtime, so I was hoping they would let you fix whatever can/should be fixed.

    Hopefully this isn't an indication that the same applies to the rest of the BCL and WinFX/.NET 3/whatchamacallit.

    Thanks for the info.
    Wednesday, May 20, 2009 8:17 AM
  • I'm glad the developers at Microsoft are finally implementing real applications in WPF (i.e. Visual Studio) so they see what developers in the real world have to struggle with when we attempt to adopt these new technologies.  This problem has been reported since before .NET 3.0 was GA'd, and I've been dealing with it in every listview, treeview, and flowdocument ever since.  Trying to get the user not to scroll their document or notice the blurry nodes in a newly expanded tree view is both a fun design challenge and a major headache.  When I saw it continuing to happen in the VS 2010 beta, I was disappointed.  It's good to see there is a major update coming to text rendering.
    Monday, June 01, 2009 9:31 PM
  • It is good to see that MS actually use WPF as well yeah and I really hope this update in 4.0 cures the blurry text issue once and for all.

    One other thing that might be related (or maybe someone can tell me a fix/workaround?) - if I apply a drop shadow effect to a TextBlock the text gets incredibly blurry no matter how I configure the effect... Is that also going to be fixed in ths 4.0 update?
    Windows XP MCP
    Monday, June 01, 2009 10:29 PM
  • It is good to see that MS actually use WPF as well yeah and I really hope this update in 4.0 cures the blurry text issue once and for all.

    One other thing that might be related (or maybe someone can tell me a fix/workaround?) - if I apply a drop shadow effect to a TextBlock the text gets incredibly blurry no matter how I configure the effect... Is that also going to be fixed in ths 4.0 update?
    Windows XP MCP

    Yup, it's been fixed with the addition of the new CleartypeHint feature.  I discussed this in an earlier post on this thread, but here is the recap:

    This is because WPF defaults to turning off cleartype when rendering text into intermediate render targets, because the cleartype rendernig algorithm only looks correct when rendered to an opaque surface (because cleartype effectively triples the horizontal resolution of your display, and there is only one alpha channel per pixel on any normal render target, vs. the three alpha channels per pixel that would be required to render cleartype in an alpha-agnostic manner).

    We are adding a feature in WPF 4.0 called CleartypeHint that will allow you to override this behavior and force WPF to render with cleartype into intermediate render targets.  You should only use this when you know your IRT will be opaque.  It is useful when you want to use cleartype with ShaderEffects, in Layered Windows, and in any other situation that would otherwise turn off cleartype (VisualBrushes, DrawingBrushes, 3D, etc).

    David
    Monday, June 01, 2009 11:12 PM
  • David,

    Thanks for the prompt response, glad to hear that this will also be fixed in the new version then :)

    Cheers
    Chris
    Windows XP MCP
    Monday, June 01, 2009 11:18 PM
  • The real problem is of course that pixel snapping and bitmap hints have previously always been off. I'm looking forward to the fixes in 4.0, and hopefully we can once again get legible small-type text in applications. It is, after all, the year 2009, and bitmap displays have been around since 1984 (or earlier, if you were a Tektronix fan :-)

    XNA/DirectX MVP 2006-present
    Tuesday, June 02, 2009 5:58 PM
  • Well I'm certainly looking forward to seeing what the difference is in Beta 2. Currently WPF text looks amazing on high DPI displays, I do hope the improvements don't harm that, especially given that a lot of developers are going to be enabling the new behaviour solely to get sharper text at 96dpi. I suppose we can at least hope that it finally moves developers over to WPF and the slew of applications that don't work at high DPI will slowly disappear.
    Wednesday, June 03, 2009 1:02 PM
  • It's great that text blurriness finally gets fixed.

    As I understand it, MS finally introduce "compatible width" rendering into the WPF pipeline, which previously was "ideal width" only.

    What are the consequences? "Ideal width" has the promise to have the same layout at any DPI. Will my layout potentially change with the the DPI settings? Is that the reason for the opt-in David Teitlebaum mentionned?

    Hopefully we will NOT have the same issues as GDI+ had. As a reminder: text widths were inaccurately reported by GDI+ (because of grid-fitting the actual text width on screen was usually smaller than the measured text width). This was a nightmare and text that was supposed to be centered in a shape was sometimes very apparently offset to the left. The workaround was to use antialiased text... yeah you guessed it: blurry. :-(

    Can someone at MS elaborate on the text tradeoffs being made in .NET 4 and the consequences compatible width rendering will have on layout and measurements?
    Sunday, June 07, 2009 11:02 PM
  • I installed VS2010 and .netfx 4.0 and it looks like a ____ of bluriness and performance lags. Will not use it as it is now. Hope at least something will change untill the final release.
    Thursday, June 18, 2009 8:55 AM
  • As David states above, the text improvements aren't in Beta 1, you should see improvements when the Beta 2 builds are released.

    Thursday, June 18, 2009 9:01 AM
  • Hope you are right, thanks.
    Thursday, June 18, 2009 9:05 AM
  • Hopefully we will NOT have the same issues as GDI+ had. As a reminder: text widths were inaccurately reported by GDI+ (because of grid-fitting the actual text width on screen was usually smaller than the measured text width). This was a nightmare and text that was supposed to be centered in a shape was sometimes very apparently offset to the left.
    This is a very important point. The metrics must correspond to the display. When in ideal mode return ideal metrics. When in compatible mode return compatible metrics.

    Because of the GDI+ problem you mention, in my WinForms app I don't use Graphics.DrawString() method because there is no way to get the corresponding metrics. So I use interop to call Win32 methods.
    Friday, July 10, 2009 5:01 AM
  • When will the Beta 2 be available for download?
    Thursday, August 06, 2009 5:42 AM
  • Because of the GDI+ problem you mention, in my WinForms app I don't use Graphics.DrawString() method because there is no way to get the corresponding metrics. So I use interop to call Win32 methods.

    You shouldn't need P/Invoke for that - since 2.0, WinForms include class TextRenderer, which provides static methods encapsulating GDI (rather than GDI+) text rendering - DrawText, MeasureText etc.
    Thursday, August 20, 2009 8:58 AM
  • For more detailed information on the new text rendering and text formatting features comming in WPF 4.0 (including API & screenshots), please refer to this blog post on the WPF Text Blog. http://blogs.msdn.com/text/archive/2009/08/24/wpf-4-0-text-stack-improvements.aspx
    Thursday, August 27, 2009 6:24 PM
  • For more detailed information on the new text rendering and text formatting features comming in WPF 4.0 (including API & screenshots), please refer to this blog post on the WPF Text Blog. http://blogs.msdn.com/text/archive/2009/08/24/wpf-4-0-text-stack-improvements.aspx
    Awesome. I think everyone is going to be really happy about this.

    This is as much flexibility as we could possibly ask for.

    Thanks!
    Thursday, August 27, 2009 8:45 PM
  • Hola Ivan.

    Asi que VB...yo trabajo con c#. Que pequeño es el mundo.
    Por Granada?
    Friday, October 23, 2009 9:10 AM
  • Well I downloaded the .NET Framework 4 BETA 2 and so far the text does look a bit clearer but I havent properly tested this yet. However, I notice that the Image property RenderOptions.BitmapScalingMode (or something like that) seems to have disappeared - this is bad because that was a useful property to set to make your images less blurry.
    Also, speaking of bluriness - when in the XAML editor, the intellisense window that appears when you start typing has very blurry icons for properties, namespaces etc. Its weird though because the items at the top of the intellisense list are crystal clear, its only icons for items near the bottom of the list that are blurry.
    Friday, October 23, 2009 5:44 PM
  • RenderOptions.BitmapScalingMode should still work in 4.0.  What do you mean by "disappeared"?
    Monday, October 26, 2009 6:46 PM
  • I mean, if I create a new image via the XAML editor like so:

    <Image Source="C:\myimage.png" />

    Then I click into the Image tag (just after the image path) and type Render then nothing appears in the Intellisense list that matches that apart from RenderSize. I foolishly assumed that Intellisense was good enough to actually rely on now but obviously this is not the case as I just tried typing RenderOptions and then a full stop and then it brought up the possible properties (BitmapScalingMode etc) in Intellisense after that.

    So at least I have now found that the option is there... you just have to type it out in full rather than using Intellisense to select it.

    Chris
    Wednesday, October 28, 2009 7:26 PM
  • So has anyone that posted in this thread had chance to try out .NET 4.0 and see if they find the text to be much clearer in WPF apps now? :)
    My blog: http://cjwdev.wordpress.com
    Monday, June 07, 2010 10:53 AM
  • So has anyone that posted in this thread had chance to try out .NET 4.0 and see if they find the text to be much clearer in WPF apps now? :)
    My blog: http://cjwdev.wordpress.com

    I just converted my application and confirm so. It's just alot better now. You should try it yourself.
    Maximilian Haru Raditya
    Monday, June 07, 2010 2:26 PM