Enable Software Rendering in WPF programmatically

From my previous post, I talked about troubleshooting WPF graphic issues. One of those options is to set a registry key to enable software rendering for WPF on that machine only. But that can be an intrusive setting and may not suit everyone’s needs.

There is a another option, which is to enable software rendering in code. If you are working on .NET 3.5 framework, there’s a way to set that up..unfortunately you have to set that up per window or per target control. But might be useful for those that want to selectively tweak rendering mode for each window.

private void ConfigureSoftwareRendering()
    if (shouldEnableSoftwareRendering)
        HwndSource hwndSource = PresentationSource.FromVisual(this) as HwndSource;
        HwndTarget hwndTarget = hwndSource.CompositionTarget;
        hwndTarget.RenderMode = RenderMode.SoftwarewareOnly;

If you’re developing in .NET 4 framework, then you have another option, which is to set up software rendering per process….like so.

public partial class App : Application
    protected override void OnStartup(StartupEventArgs e)
         if (shouldEnableSoftwareRendering)
            RenderOptions.ProcessRenderMode = RenderMode.SoftwareOnly;

You might be wondering why we should use software rendering for WPF applications. It depends on the end-user hardware configuration which might have “WPF-unfriendly” drivers, or just no graphics card. In some situations software rendering might be faster than hardware rendering … hope this helps.

Share this post :
Posted in WPF. 4 Comments »

Graphic issues with WPF

Graphic issues with WPF are not uncommon at all. This may be partially due to graphic card drivers having varying effects with hardware rendering on WPF applications . The same application may look different on PCs with different hardware specifications. In our situation, we had an image rendering with jagged lines on a couple of PCs, and looked fine on others.

In order to troubleshoot if it’s a hardware problem, or your code, I find that the simplest approach is to first disable hardware rendering on your machine, by modifying a registry key. That registry key might not be on your machine, so add it if it isn’t.  By default if that key is absent, WPF assumes hardware rendering should be enabled.

After you reboot, and the graphic problem has disappeared because your PC is now using software rendering, you know for sure that your code is fine. Next you will have to update your graphics card driver, computer bios, and make sure you have at least .NET Framework 3.5 SP1 installed.

Here’s a link for Guidelines for troubleshooting graphic issues on WPF. It’s quite useful, and covers what I discussed above. Give this a go, it has helped identified our graphics problem very swiftly.

Posted in WPF. 1 Comment »

ResourceDictionary: Use with care

Seems like WPF is plagued with memory leaks and problems, if not handled with care. Resource dictionary is another potential pain point, the current project I’m working on is one such victim.

Consider an UserControl that references a ResourceDictionary in it’s MergedDictionaries. Consider that the referenced ResourceDictionary references other ResourceDictionaries, and so on. Now consider that you render 30 of these user controls on a window, each user control creates a unique instance of the same ResourceDictionary, plus much more. Now you suddenly have heaps of memory being allocated, unnecessary memory for that matter. Apparently this occurs in .NET 3.5 only, not 4.0.

Read the rest of this entry »

WPF DynamicResource memory leak

After some troubleshooting on WPF memory leaks, I came across a memory leak that occurs when using DynamicResource on resource keys declared in Application.Resources. You can read about this problem being discussed on msdn forum and stackoverflow. To fix this problem, fortunately there’s a patch for .NET 3.5 and .NET 4.0 resolved this issue.

If you’re developing in Silverlight, no issue as there’s no DynamicResource. If you’re developing in WPF, I urge you to consider if there’s a need at all to use DynamicResource. If you’re not using SystemColors, SystemFonts or themes in your application, StaticResource should be considered because DynamicResource are re-evaluated at runtime whenever the resource is requested which is an overhead. If you’re not familiar about their usages, you can read more about them here.

Posted in WPF. Tags: . Leave a Comment »

WPF memory leaks

After working on a WPF application for a couple of months, I’ve noticed that the application was leaking a large chunk of memory. After some memory profiling, the culprit was not very apparent. It seems that it was a combination of issues that contributed to the leak. One of the biggest problem was that data-binding was not done “properly”.

So what do I mean by “data-binding not done properly? Apparently if your DataContext does not implement INotifyPropertyChanged, you’re in big trouble!! Here’s a link from Microsoft that explains the phenomenon….

After much research, I came across a fantastic article explaining all the possible errors one can make to cause a memory leak. Some of these are not WPF inherent problems, they are just typical memory leak culprits dominant in all .NET applications, e.g. failure to unsubscribe an event handler; while some are just obscure and weird. But rest assured that some of the weird ones are fixed in .NET Framework 3.5 SP1 and .NET Framework 4…. So if you develop in WPF, this article is a MUST READ!!!!!

Lastly, a word of caution. Remember to start performance testing and memory profiling quite early in the stages of development. It’s a misconception that these activities can be put off until the late stages. If you do that, you have to bear the consequence of not being able to fix these problems because it becomes too hard to change code and change design…you have been warned.

Share this post :

Upcoming new features for WPF 4

Scott Gu has released new feature for WPF in the upcoming VS 2010 and .NET 4 framework.

Read about it here. I must say I’m looking forward to playing with it, very impressive.

Posted in WPF. Tags: . Leave a Comment »

WPF: Window Dock Behavior

**updated this post for Blend 3 RC release

Have you ever used WinSplit Revolution? It’s a utility that helps you organize your windows into regions to assist with organizing your screen real estate. I find this to be a very useful tool, especially when I use two monitors while doing development, being able to organize my windows neatly makes a huge difference. One cool feature is called Drag’n’Go. When you drag your window outside your screen boundary, a semi-transparent rectangle (I’d like to call it an overlay) appears to cue you on the location of where the window will be docked. I really like this feature, and wondered how difficult it would be to incorporate this into a Behavior for a Window class in WPF to exhibit the same kind of functionality. Here’s my result.


Read the rest of this entry »

Posted in WPF. Tags: . 2 Comments »