I was wondering: are you satisfied with the text-rendering in the Visual Studio 2010 editor (Beta 2)? On my primary monitor it looks very blurred, even when using font size 12!
When using font size 10 or 11 it's horrible. Can the WPF text rendering mode be set explicitly for VS code window?
EDIT: I am using Windows 7 x64 and my primary monitor is a Benq G2412HD. What's kind of strange is that the font seems to be nicer on the secondary monitor, which is a 4 year old 19' TFT.
EDIT: I tried several Cleartype settings but none really looks as nice as when using Visual Studio 2008.
The first image is from the primary monitor, the second from the secondary. Both are using Consolas 10pt (my preferred font).
Primary screen http://img4.imageshack.us/img4/6789/vs2010.png
Secondary screen http://img4.imageshack.us/img4/7986/vs20102.png
I use Consolas size 10 and I have no issues.
Try following the instructions on Microsoft's website for tuning clear type. You can find it here.
If you use IE when accessing that website, you can make changes to clear type settings right from the browser.
TextSharp is the answer right now. I really hope they continue to fix this issue because I've had terrible results on my primary and secondary monitors with the standard rendering. Using beta 2.
With 8 or 9pt Lucida Console the text is fine with text mode set to 'Aliased'.
Here is how VS2008 and VS2010 beta2 editor text rendering looks for me, side by side. The font is Consolas 13pt.
VS2008:
http://int19h.org/so/cleartype_vs9.png
VS2010:
http://int19h.org/so/cleartype_vs10.png
I don't see any observable differences.
[EDIT] Okay, I've reproduced it with the color scheme posted. It seems that the key part here is to use bright text on dark background. With dark-on-bright, the output seems to be the same.
Here's some guesswork. Apparently, Direct2D (which WPF uses for antialiased text output) always "gives precedence" to foreground (i.e. text) color over background color when doing subpixel antialiasing. On the other hand, traditional GDI ClearType seems to always give precedence to dark colors over bright ones. Thus, with bright letters and dark backgrounds, ClearType text becomes thinner, but Direct2D text remains of the same size, pixel-wise. Furthermore, as bright pixels are more intensive, the same amount of them "stands out" more with same foreground/background contrast, so bright-on-dark D2D text looks noticeably "bolder".
Well I experience the same oddity (not only in VS2010, but in all WPF applications). Sadly there seems no way of setting a "backwards style" text rendering in WPF in general.
I just found this addon "Text Sharp" for VS2010 on the VS gallery which lets you select different font aliasing options for the VS2010 text editor, but at least for me, this didn't help with the issue.
Here is the link, if you might want to try it: Text Sharp VS2010 extension
Please have a look at the screenshots in the following update (to come in final release of VS2010), and see if the improvements solve your issues with VS font rendering:
http://blogs.msdn.com/text/archive/2010/03/05/additional-wpf-text-clarity-improvements.aspx
http://blogs.msdn.com/visualstudio/archive/2010/03/11/wpf-text-clarity-improvements.aspx
Have you ensured that ClearType is enabled on your OS? I've seen similar issues with 2010 when ClearType was disabled on my machine. Re-enabling ClearType made the Text snappy looking again.
For some reason the ClearType setting on my OS kept getting undone when I TS'd around a bit. I had to reset it a couple of times but it seems to have calmed down recently (I believe I was using a Pre-RTM build of Win7 at the time).
Try using Courier New font.
Tools -> Options -> Environment -> Fonts and Colors
ollifant I agree with you, they are different.
Others may not see any differences from screen shots, but on the actual machine I can see differences. Loading the same project with the same settings side by side looks different. I think it is the difference in how WPF renders fonts or something.
The VS 2010 pane looks shifted slightly left, like kerning in the font is off by a little or something. Again - same font in both VS 2008 and 2010.
I have tried now on Windows 7 and Windows Vista. Maybe older XP machines render differently, can't say (and no I won't load XP to find out).
I have noticed a rendering problem with Visual Studio 2010b2 as well.
I've tried adjusting the clear type settings to no avail.
I use consolas 9 pt on win7x64 with a average 19 inch TFT.
This is what it looks like on my system.
A side by side screen shot
OK here's what you do. Finally figured it out!
You need to reset cleartype to the default values. Don't try to tune it based on what you think looks good - because what you think looks good won't in VS2010.
I noticed on a brand new install of Windows 7 my VS2010 text suddenly became a lot nicer. After running cleartype to try to get nice text on a wall mounted Sony TV I found it had totally screwed up text for my normal external monitor.
I haven't yet found a way to reset cleartype explicitly, but apparently the below explains what the defaults are :
When you open ClearType Text Tuner,
select "Turn on ClearType" check box
and click on Next. Then, again click
on the Next after setting Native
Resolution. Then, select the options
as given below:
1st Screen – 1st Option out of 2
2nd Screen – 2nd Option out of 6
3rd Screen – 1st Option out of 3
4th Screen – 2nd Option out of 6
Finally, click on Finish.
This is for VS2010 RC.
Related
We have a Windows Forms application used for testing our products that has had pretty much the same forms and dialogs for nearly 10 years now. AutoScaleMode in the designer is set to Font for both forms, and that hasn't changed since the original design. AutoSize is set to false and just for good measure (I guess) AutoSizeMode is set to GrowOnly. The following source lines are in Program.cs:
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Remember, this has been working flawlessly for years...
One of the recent updates to VS2017 included AutoScale support for monitors with different DPI. I have a relatively high DPI monitor, so when I made some changes to a Settings dialog (adding controls, etc) I started getting bright yellow banners cross the top of the designer surface telling me that AutoScaling was set to 125%, and would I like to change that? I tried going back and forth, and when in 100% mode (Autoscaling off) I was warned that XAML forms might not display correctly. Fine, I am working with Forms so I went back to "normal" scaling and the form looked fine.
Until I tried running the program. Now when I start the program the main form looks like this (details deleted to protect the guilty):
...but when I open the settings dialog it looks like this:
Yikes! It looks worse in practice, the relative images here don't do justice to the difference in size and scale.
I have no idea what got changed or how / why this is happening, but there's no way I can put this into production. I've tried changing the AutoScale settings, to no avail. Can somebody point me in the right direction here?
Thanks in advance!
EDIT: It seems the rescaling only happens on my machine when I run the app in Debug. Whatever is messing up the display of the forms on my machine doesn't do that on my associates' machines and isn't replicated to the executable produced by the build server.
On another note, I tried every DPI-related setting I could find, added those that weren't there due to the program's age, all to no avail. Nothing I have tried has had any effect on the program's display weirdness on my machine. Ugh.
I tried all the tricks I could find, short of disabling AutoScale completely, and nothing worked. I finally merged our develop branch in to my feature branch and inspected all 270 edits, choosing the oldest settings I could find for all size parameters, all controls. Ugh.
Along the way I stumbled across the following line in the Designer.cs file for the form:
this.AutoScaleDimensions = new System.Drawing.SizeF(6F, 13F);
This setting is NOT accessible from Visual Studio's designer, as far as I can tell, nor can I find anything about how or why it gets set. What I did find was that in the earlier version that did work as expected, the values were (8F, 17F) -- so I manually edited the line to match the older, working version. Success!
I also checked my Windows display settings, and the Custom Scaling value was at 100%, so I used the registry hack mentioned in one of the articles I found following the first link from the comment above (thanks, #Jimi) to disable auto-scaling in Visual Studio, then turned off the notification. Now I'm (finally) back in business.
Registry hack is here:
https://learn.microsoft.com/en-us/dotnet/framework/winforms/disable-dpi-awareness-visual-studio
If one uses the registry hack mentioned in the answer from DaveN59, and there is already entry for your ...\devenv.exe (mine was previously set to run as admin) then add the DPIUNAWARE string to the end of the "Data". Make sure to use a space as a separator.
Example: ^ RUNASADMIN DPIUNAWARE
I'm not sure what the ^ is for, but it was there and I just added DPIUNAWARE string. Also, if you just add this string, it will come up unscaled, but you will still see the yellow banner. To turn that off you'll need to select that option from with in Visual Studio. The instructions are in the link for the registry hack, also provided above. For conveinece here's the menu navigation path.
To disable notifications, choose Tools > Options to open the Options
dialog. Then, choose Windows Forms Designer > General, and set DPI
Scaling Notifications to False.
I have a WPF application which runs fine on Windows 7 OS. But the same app crashes on a particular few Windows XP machines.
It runs fine on few windows XP machine. but on a few XP machine it fails to start.
ERROR - Image format is unrecognized.
I know this question has been asked few times. but my problem is i am still not able to figure out as to how to resolve this.
Should I change the .ico used for the application ..
Unfortunately, simply removing the 256x256 application isn't the greatest solution when you want to support the large icon size for Windows Vista, 7, 8 and forward.
Another way to solve this problem ... is to not compress the 256x256 image in the icon. See this forum thread for more info.
How does one do that? Well, most icon utilities will have an option for this (as this is a common problem). I use IcoFX and below you can see the option (highlighted in red) I needed to clear.
I've had a bit of fun with this problem this morning. It turned out that the error was occurring only on XP machines where the colour settings were set to 16 bit, and when I changed it to 32-bit the problem magically disappeared.
This goes for XP (including Embedded) SP3.
In your WPF application you will have at least two places to set icons:
The application icon. This is used for displaying the application in Explorer, desktop, etc. You set this in the project properties.
The window icon. This is used as icon in the upper-left corner of the window, and perhaps for alt-tabbing and on the taskbar. You set this as the Icon property on the window.
Often, you may use the same icon file in both cases. However, if you have a compressed 256x256 icon as window icon, then this can crash in Windows XP. This is what you are experiencing. On the other hand, this not the case when the application icon has a compressed 256x256 icon.
So another solution (which I implemented in all my projects) is to have two icons: The application icon (which contains all sizes) and a special "window icon" version, which only contains the sizes 16x16 and 32x32 (since those are the only sizes which are used).
If I remember correctly Windows XP does not support icons larger than 48x48 pixels and this could be the reason for the crash. .ico files should definitely run on both systems.
You can create an icon that support multiple sizes, so if you add 48x48 and for example 256x256 in the same file you should be good. Also be sure to use select a good software to produce the icon when making icons that support multiple sized. I've used Greenfish Icon Editor which I think works fine. But there are multitudes of other products for this.
Be sure to read The ICON handbook, section Windows, it contains good info about what icon sizes and bit depths to use.
Other threads on SO supports my belief:
problems with icon image
Which icon sizes should my Windows application's icon include?
Another workaround to (16/32bit resolution problem) is not to define icon in XAML, but load it in code:
this.Icon = new BitmapImage(new Uri("pack://application:,,,/UserInterface;component/Resources/Icons/ReportViewer.ico"));
It's well documented (e.g. here) that IE9 ignores the OS-wide settings for font smoothing (aka anti-aliasing). Even if font-smoothing and ClearType are disabled in Windows, IE still shows anti-aliased fonts, which some users struggle to read, especially at small font sizes.
How can I disable all font anti-aliasing (ClearType or otherwise) in IE9?
More details:
Our company builds a web application which uses a lot of small fonts. With the release of IE9, some of our users have complained that IE9's default anti-aliasing makes our small fonts fuzzy or blurry. So we need to help our users who've installed IE9 and who want to turn off anti-aliasing.
Also, personally, I have trouble reading small, anti-aliased fonts, so I'd like a solution for my own use, even for sites I don't control.
In IE8 I could uncheck the "Always use ClearType for HTML" and then disable ClearType in the OS and IE8 would show all fonts aliased. But in IE9, this option is missing.
After some research about the problem, here's what I've learned: the core issue is that IE relies on DirectWrite for text rendering and does not support any of the newer rendering options which would draw text without anti-aliasing and respect the user's OS-wide default choices.
Making things worse, if you disable ClearType in the OS, in some cases IE will fall back to DirectWrite's default non-cleartype anti-aliasing which is even fuzzier than ClearType.
After a few days of searching, I found an MSDN Forums thread which pointed me to a solution here: http://www.softwareninjas.ca/dwrite-dll-wrapper
Follow the instructions on that page and you'll remove anti-aliasing from IE9 (at least the 32-bit version of IE which is the default IE, even on 64-bit Windows 7). I've tested it so far on a Win7 x64 laptop and it worked flawlessly.
Big thanks to Olivier Dagenais who built this. Here's a technical summary of how his solution works.
It's a two-step process. First, you need to disable ClearType in IE via a registry key. This is the same setting which was available in previous versions of IE, but it was removed from the IE UI because it stopped working in IE9.
[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main]
"UseClearType"="no"
Second, now that ClearType is disabled, Windows will fall back to a non-cleartype anti-aliasing solution. Now that fallback anti-alising also needs to be disabled. Quoting from the thread above:
What is left is the font smoothing
(aka sub-pixel rendering), and that is
the "blurring effect" you still see
after turning cleartype off.
In case you were wondering, there is a
way to turn that off too.
The method i used to turn off the
sub-pixel wonder is to build a simple
wrapper for dwrite.dll which
intercepts and forwards calls to the
real dwrite.dll, disabling font
smoothing in the process.
You can download it from: http://www.softwareninjas.ca/dwrite-dll-wrapper
You can find the code at
https://softwareninjas.kilnhg.com/Repo/Open-Source/Group/DWrite-dll-Wrapper
This was a pretty cool hack. Probably somewhat brittle across windows and DirectX releases, but will do the trick for now until Microsoft gets their act together to fix the underlying "can't disable anti-aliasing" problem in IE itself.
It also works for apps which use the IE WebBrowser control (aka MSHTML), so you can control anti-aliasing on an app-by-app basis. It also works for the HTML Help viewer.
Note that the text quality in IE9 standards mode isn't ideal. Specifically, small fonts sometimes have letters sometimes run together without the usual one-pixel space between them. If you render the same page in compatibility mode (or your site uses a non-strict DTD or other non-standards-enforcing DTD), then it looks fine. So there's an additional step for some sites if they want the best aliased text rendering: just view a site in compatibility mode by pressing the compatibility button in IE's toolbar.
To answer your question directly:
ClearType font rendering is used in all IE9 document modes; sub-pixel
positioning is used only in IE9’s
default standards mode. IE9’s
compatibility modes—Quirks, 7, and
8—use whole-pixel text metrics.
So try switching your doctype to use Quirks mode:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
The other thing to consider is to try avoid point based font sizes.
Important information regarding fonts, blurriness and rendering in IE9
IE 9 does not use sub-pixel antialiasing under certain conditions
MSDN sources:
Sub-pixel Fonts in IE9 - blogs.msdn.com/b/ie/archive/2010/11/03/sub-pixel-fonts-in-ie9.aspx
IE9's blurry font text - www.hanselman.com/blog/TheUltimateGuideOfFiveThingsForNewIE9UsersWhoFearChange.aspx
Defining Document Compatibility
Documents Mode
The info here solves two problems:
1. Getting rid of cleartype and font smoothing in IE9
2. Getting rid of cleartype and font smoothing when IE10 is installed or installs itself automatically
I had done a registery hack to turn off cleartype in IE9:
[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main]
"UseClearType"="no"
and used a little piece of freeware to get rid of font smoothing in IE9:
https://softwareninjas.kilnhg.com/Repo/Open-Source/Group/DWrite-dll-Wrapper
Then IE10 automatically installed itself and the blurry type was back. I tried uninstalling IE 10, which wasn't through the add/remove programs interface but rather through the installed updates interface--removing the IE10 update. That ostensibly took me back to IE9, but the blurry type remained in spite of the fact that "no" was still the answer for cleartype in the registry and the two .dll files were still in my IE program folder.
So, I decided to uninstall IE9 and reinstall it. That also involved going through the installed updates interface and removing the IE9 update.
I rebooted and expected to have to reinstall the program, but my IE icon was still there. When I clicked it, IE9 opened with nice, sharp type.
I'm trying to use an existing internal WPF application (I do have access to the source), but it was developed on XP and I'm using Windows7 64-bit.
When I click (for instance) the File menu, 90% of the time I see no drop-down menu at all. The menu still exists - I can use the arrow keys to navigate up and down and choose an option if I happen to know the order of the options, but nothing renders at all.
The other 10% of the time, the menu or some portion of it DOES render, but as I move the cursor up and down I get graphical corruption or disappearing options until I end up back at the "no menu is visible at all" state.
This is also true of combo boxes within the application - they show no data when I drop them down, but I can arrow down and choose an entry.
Microsoft has some advice about WPF rendering issues here but none of these steps has helped with my issue.
Edit: a coworker running Windows 7 sees the menus just fine... he has a different video card, so I'm curious whether this is video-card specific.
This also sounds similar to an issue we had seen in XP, where comboboxes (or menus) would not display properly some of the time. There is a Microsoft hotfix (for at least one flavor of it) here, but unfortunately it is for XP and WS2003. I'm not sure if this could point you in the right direction.
The link to this hotfix was found in this MSDN thread. I am not the author of this particular link, although I do remember raising this issue some time (and a different job) ago.
It turns out that in this specific case, the issue is only present on boxes that have a GeForce 6800 video card. Updating drivers has no effect, but switching to a 7800 makes the issue go away.
I have no idea why this is the case, and I haven't found any information online about 6800-specific graphical issues in Win7 64, but our testing and experimentation shows this is the factor that causes it.
Crazy.
See this question. It's probably a problem with a DropShadowEffect, removing the Effect should fix the problem.
I second that the issue is related to NVidia Windows 7 x64 drivers. Recently I had to replace my video card. Now I have Quadro FX 3400 with the latest drivers and am seeing similar behavior. WPF ComboBoxes don't render dropdown portions. I can only switch values with keyboard after a few attempts. It could be Direct2D-related issue. I also had to turn that off for Firefox to start working again.
I'm having problems with the rendering of a WPF app over a remote desktop connection.
The applications chrome is rendering, but none of the content is coming through, as if the window is not drawing. Instead the previous content of the screen is showing in it's place.
This has been a problem with the application running on both Vista & Win 7, with remote control being taken from XP and Win7.
The problem is not application specific, if I create a new WPF app, with just a textblock on the window, it will also not run. (Neather will the windows preview in VS2008 display.)
Is there some trick to getting WPF running under RDP?
I read on Kevin Dente's blog (from a twitter post) that he was having trouble with WPF apps in virtual machines. While not the same as Remote Desktop, it's possible the problem could be the same. Kevin was able to fix his problem by disabling hardware accelleration by creating a DWORD registry value at
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Avalon.Graphics\DisableHWAcceleration
and then setting it to 1.
His original blog post is here: http://weblogs.asp.net/kdente/archive/2009/10/19/visual-studio-2010-beta-2-editor-performance-fix-running-on-a-virtual-machine.aspx
That may not be your exact solution, but maybe it points you in the right direction.
WPF should render over RDP; it's smart enough to know when it can render in hardware, and when it can't it reverts to its own GDI+ based software rendering. I would make sure you're running .NET Framework 3.5 SP1 on the remote machine, since there were changes to remoting that might pose issues. (See link below.)
I've been developing a WPF app for the past 6 months and it works just fine over RDP. (From Vista and Win7 to XP, Vista and Server 2003.) One important caveat, however, is that it renders using the Classic theme. So if you're using controls that don't have a classic theme, they won't render. If you're just dropping a TextBox on a Window, then obviously that's not your problem.
Check out this question for some links that may be helpful: Are there problems with rendering WPF over Remote Desktop under Windows XP?
I just had this problem with the ribbonwindow not displaying correctly when testing for the first time via RDP - the transparent background was white, the close minimize/maximize buttons were missing, the rounded corners on the bottom of the window were square, and the top row of ribbon buttons were almost impossible to select.
Turns out there was a simple fix for me. Right-click the RDP connection icon (I have it saved on my desktop), select "Edit", then the "experience" tab, and change "detect connection quality automatically" to "LAN (10 Mbps or higher)".
This fixed it for me.
Ade
Did you also try Win7 latest RDP - Win7 connection? The thing is WPF doesn't use GDI to draw elements.
VNC clients (like UltraVNC) probably will do the trick for you as they using much simplier algorithms more like of sending bitmaps.
I have the same problem than the asker. The standard, out-of-the-box Checkbox is not rendering correctly. I can only see if it is checked when hoovering the checkbox. Otherwhise, no difference between checked and unchecked. Important note : It occurs when setting the foreground to white (see here : https://social.msdn.microsoft.com/Forums/vstudio/en-US/1c03db49-7e53-4cbb-9dd1-b328017c4453/wpf-checkbox-and-radiobutton-check-mark-not-showing-under-xp-windows-classic-theme-and-remote?forum=wpf)
Our application used to have this problem with a custom progress bar.
We fixed this by setting the background color of the Border control to White. This leads me to think there is an issue with transparent backgrounds
There is no special trick needed to get WPF content to show across remote desktop. Our WPF-based app renders just fine over RDP (tried from numerous machines) with no problems. We're even using animations, gradients, WriteableBitmap, etc. w/ no problems.