§ ¶WPF text hinting (or lack thereof)
One of the problems with Windows Presentation Foundation (WPF) has been its lack of text hinting. Text hinting adjusts the position of glyph curves to better match the grid, resulting in better legibility because stems appear sharper than if they were positioned between pixels. WPF omitted text hinting in order to attain resolution independence, but this resulted in illegible text at small point sizes, such as that commonly used in UIs. If you've ever taken text and resized it in an image editor, you're seeing a similar problem.
Visual Studio 2010 is switching to WPF for its text editor and parts of its UI, which led to some concerns about text readability. Some work has been done with WPF 4.0 to add back in hinting support, which I can say seems to have worked in beta 1:
These screenshots were taken with the default Consolas font and with the Lucida Console 10pt font I use with VS2005, on Windows 7 RC. It looks fine. I suspected that maybe VS2010 was still using WinForms, but I verified that there's no WinForms container window in Spy++, and you can also tell by the caret, which curiously changes width slightly as it moves. I wouldn't have thought that the caret would require hinting as well, but I can say now that it definitely looks weird having the caret antialiased. I also have to say that, unlike the old Courier New default that I hated passionately, the new Consolas default looks pretty good. It takes more space vertically than Lucida Console, but it takes less space horizontally and looks sharper. I personally like ClearType, though; those who don't are a bit stuck, as I don't believe you can turn it off in VS2010.
Unfortunately, while the text editor looks good, the menus are a different story:
Ewwww. Apparently I'm not the only one to notice this, based on the forums. I don't think I could stand it if the text editor looked like that. Text hinting is good.
Side note: I wanted to post whether VirtualDub compiled with VS2010 out of the box, but I can't figure out how to integrate the DirectX SDK. The VC++ Directories option seems to have gone missing with the switch to MSBuild, and I can only find it as a project setting now. The last thing I want is to bake a system-specific path into a project file. Hmmm.
Hinting isn't optional in 2009. It's unbelievable that they'd release any UI without it; that's just a bad joke. It's as essential in a modern text engine as antialiasing itself.
Glenn Maynard - 22 05 09 - 23:09
asf - 22 05 09 - 23:24
That's a different issue than hinting -- that's WPF forcing antialiasing on. I haven't used Dina, so I don't know whether it's a bitmap font or whether it's a TrueType font set to not antialias at that font size.
Phaeron - 22 05 09 - 23:57
re: Side note:
Doesn't the directx sdk installation set the Env. var DXSDK_DIR to the sdk installation ?
I would think MSBuild could be persuaded to evaluate $(DXSDK_DIR)\lib\x86/x64 $(DXSDK_DIR)\include ?
Henrik - 23 05 09 - 01:19
It might, but I don't actually install the DXSDK on all my OS partitions. On my Vista64 install, I just point to the include/lib dirs on the XP partition and install the developer runtime. It's convenient to be able to use SDK includes and libs directly without installation, particularly if you have to deal with multiple versions. This is especially handy on an automated build system.
The question is not so much what path to use as where to put it. There doesn't seem to be any global place in the UI anywhere to enter paths. I ended just hacking it into my property sheets, but it'll be a mess if every project has its own way to do this.
It turns out that failing to build Hello World is the least of the problems with VC++ in VS2010 beta 1 -- there have been so many problems in the project system that I still haven't gotten VirtualDub to build. I'm logging the bugs as I isolate them, but the problem I'm hitting right now is that I can't get custom build rules to push .obj files into a .lib. There's curiously no VC++ forum either, which leads me to believe that this wasn't really meant to be a public beta for VC++.
Phaeron - 23 05 09 - 01:32
Can you import VS2005/8 to MSBulds script in VS2010 ? (Haven't installed it myself)
Then you could place the DXSDK path in those InheritedPropertySheets that you're already using in VD 1.8.8 and see how VS2010 treats them?
VirtualDub.vcproj from vd 1.8.8:
... InheritedPropertySheets="..\VirtualDub-VC2005-IX86.vsprops ...
... InheritedPropertySheets="..VirtualDub-VC2005-AMD64.vsprops ...
... InheritedPropertySheets=VirtualDub-VC2005-AMD64.vsprops ...
VirtualDub-VC2005-IX86.vsprops with DXSDK path (replace square bracket with angle brackets):
[?xml version="1.0" encoding="Windows-1252"?]
And so on with the other platforms
At least you would only have to change the *.vsprops files.
Henrik - 23 05 09 - 03:01
Or better, just have one dxsdk_dir.vsprops that you include in all platforms and change when changing dxsdk path, but you've probably already thought about that.
Henrik - 23 05 09 - 03:22
Btw, googled this,- there seems to be some clarification about the changes with system wide includes from 2008 to 2010 here:
Quote Brian Tyler - MSFT
"...In VS2008, these directories (IncludeDirectories, LibraryDirectories, etc) were all defined in the Tools->Options window and set on a machine-wide basis. The problem with this, however, is that forced all projects to have the same values. So in VS2010, we've changed these to be project properties. Specifically, you can use property sheets to define the values and then include these property sheets to any projects that need them. Thus, rather than having a single definition, you can have a property sheet per-SDK if you wish. Additionally, if your SDK is installed in your source control enlistment instead of per-machine, you can actually check in the property sheets so the paths remain shared. Of course, you can also set these per-project as well as via property sheets.
So, now when you bring up your property pages, you'll see a new category of "VC++ Directories..."
Henrik - 23 05 09 - 03:40
Right, but you still have the same problem: where do you put INCLUDE/LIB paths in a way that doesn't require the project files to be modified? Remember, Microsoft hasn't defined such a mechanism, so everyone would do it differently, leading to a mess.
Well, except that it seems they have. It turns out that VS2010 inserts a property sheet called Microsoft.Cpp.Win32.user into the project which resides in your user directory. That appears to be the place where you put the paths that you used to put in VC++ Directories. What I don't understand is why they didn't just update the UI to edit that file.
I finally got VirtualDub 1.9.3-test2 building under VS2010 beta 1 after about six hours. I ended up having to work around about eight different project system bugs and one nasty compiler bug. Beta 1 is definitely a rougher experience for C++ than the CTP.
Phaeron - 23 05 09 - 04:14
look at the next two comments: http://blogs.msdn.com/ricom/archive/2009..
//regarding text blurryness
Tobias - 23 05 09 - 04:28
Yeah, well I suppose then that demanding that the DXSDK_DIR env.var. is set and using $(DXSDK_DIR) would provide a solution. Not uncommon with a lots of frameworks to look for their install dir env.var.
Henrik - 23 05 09 - 04:40
Oh misread it - so they provide a solution but the user have to manually edit the configuration file ?. Well c++ is/has become the stepchild of the VS family.
Henrik - 23 05 09 - 04:58
Ah, that explains why the fonts in Windows 7 don't look as sharp as in Windows XP. That was very noticeable when running a Win7 VM in a WinXP host, especially as I still use a pair of CRTs and so don't use ClearType.
Torkell (link) - 23 05 09 - 06:19
About the Consolas font, it's not *that* new. It is included with Vista and Office 2007, and has been available for download from Microsoft for some time (licensed to users of VS2005 and VS2008).
Lucas - 23 05 09 - 15:21
Yeah, but this is the first time it's been made the out-of-box default.
Phaeron - 23 05 09 - 16:14
Oh, I thought it was VS2008's default font, probably because always import my settings file in new installs (dark background, bright text)!
Anyway, I love VirtualDub and always enjoy your posts, even though they're mostly about native code. And you're too nice, nitpickers don't deserve replies ;)
Lucas - 25 05 09 - 12:35
So, is there no counterpart in wpf text handling to the way images in wpf can be made to snap to grid (aka snap to device pixels) to remove the blurring?
keije - 25 05 09 - 14:33
Text hinting is significantly more complicated than image locking because of fractional distances between glyph stems and between glyphs. If you try to fix the problem simply by snapping the position of each glyph to integer coordinates, you'll still get blurry glyphs AND you'll get funny spacing. You sometimes see a similar effect in word processors because the WP is approximating ideal spacing to show you WYSIWYG text locations. Modern font renderers use byte code hinting programs embedded in the font to push glyph vertices onto pixel boundaries, thus pre-distorting the font to appear crisp and also allow integral spacing.
I found a good thread on what's going on:
- The new WPF text stack isn't supposed to go in until beta 2. That means the crisp editor text I was seeing is probably due to improved ClearType, not hinting. It also means that the editor text is supposed to become even clearer in b2 timeframe (yay!).
- WPF currently can't render ClearType text to surfaces with alpha, which notably includes menus. It uses grayscale antialiasing instead. The resultant loss of 1/3 pixel horizontal positioning explains why the menus look so much worse in VS2010 beta 1.
This does make me wonder how WPF is rendering text. Straight grayscale antialiasing is fairly simple, but ClearType on 3D hardware is apparently more complicated -- I saw indications that Microsoft was doing three passes with ColorWriteEnable. It could be that gamma correction is throwing a kink into the works that forces the grayscale mode on translucent surfaces.
Another tidbit I dug out in my search: DirectWrite apparently doesn't support bitmap fonts either. Ugh.
If anyone thinks text rendering is easy, well, it's not....
Phaeron - 25 05 09 - 16:25