23

The title pretty much says it all. I did some Googling, but the only information I can find is at least a year old, some of the info is older than Windows 7. So I'm curious, is there a performance penalty for using WPF?

Does it work faster for somethings (such as data binding) than what you'd have to hack together on WinForms?

This will be a project created with .NET, in case that matters to anyone.

EDIT

This project I'm looking at would have a basic style of UI, however there could be a lot of information displayed (it's querying files/directories and displaying them on the screen). I have not decided if it will auto-refresh the screen, but I imagine it may.

There will likely be a fair amount of controls, however nothing that anyone should consider "graphic" intensive.

I'm looking at performance then from a business application perspective.

I do NOT plan to use 3rd party controls.

mlw4428
  • 510
  • 1
  • 6
  • 21
  • 2
    This isn't an easy question to answer... `WPF` is far too different from `WinForms`. As someone who has used both, I can tell you that the learning curve for `WPF` is steeper than it is for `WinForms`, but WPF is _much, much more_ powerful. – Brian Oct 28 '13 at 18:30
  • 1
    I'm sure it performs better in some ways and worse in other, IMHO WPF allows for better architecture patterns and there fore is easier to maintain and support. But it's purely a matter of opinion. – CodingGorilla Oct 28 '13 at 18:30
  • While that might be true, I would think Winforms uses a different rendering engine/method than WPF does. – mlw4428 Oct 28 '13 at 18:30
  • 11
    WPF is a little more resource intensive than winforms (it consumes more RAM), but the benefits of built-in hardware-acceleration, UI virtualization, and the DependencyProperty system really compensate for that. – Federico Berasategui Oct 28 '13 at 18:30
  • 1
    @user1693074 - I started learning WPF because I was curious as to what HighCore was pontificating, and I honestly haven't looked back. – Brian Oct 28 '13 at 18:32
  • @HighCore How useful is the Hardware Acceleration if we're talking what is essentially a simple UI? The target platform of the software isn't expected/required to have anything more than a simple UI. I realize now I should have this information in the question to which I'll add it now. – mlw4428 Oct 28 '13 at 18:35
  • @user1693074 Hardware acceleration is not the only benefit you get in WPF. There's also built-in UI virtualization, which winforms lacks. You might want to see [this short clip](http://www.youtube.com/watch?v=D3Y6DnFpHCA) – Federico Berasategui Oct 28 '13 at 18:37
  • @user1693074 that said, if your UI is simple, use WPF. You will not notice the performance difference, and winforms sucks. It forces you to all sorts of horrible crappy practices, as opposed to beautiful MVVM. – Federico Berasategui Oct 28 '13 at 18:39
  • 2
    "the only information I can find is at least a year old": well, WinForms hasn't changed at all since, and WPF has changed very little, so this information is probably still valid... – Thomas Levesque Oct 28 '13 at 18:44
  • 1
    Why do you focus solely on performance? WPF is the newer technology. – paparazzo Oct 28 '13 at 18:55
  • @Blam This first iteration of this program, I'm working on to be fast and compact. Perhaps in later iterations will I look at using every bell and whistle I can think of. Just because something is newer it doesn't mean it's the best. I asked the question to have a better understanding of WPF. – mlw4428 Oct 28 '13 at 19:23
  • 2
    @Brian Oh gods... the MVVM religion is spreading... – Yandros Oct 28 '13 at 19:50
  • 3
    You don't even have a detailed design and you don't know if you have a performance problem and you are selecting a technology based on solely on speed. Would you select a car based solely on fastest? What if the requirement of the car was to haul 6 children to school? – paparazzo Oct 29 '13 at 12:57

4 Answers4

24

If you're doing complex UIs, WPF is the way to go. winforms doesn't support anything.

If you're doing simple UIs, WPF is the way to go, because:

  • it allows a much cleaner pattern (MVVM) as opposed to the horrible too-much-code-for everything procedural winforms approach.
  • It has much greater DataBinding capabilities.
  • If you ever need to customize anything, you can.
  • It has built-in UI Virtualization.
  • It is resolution independent by default.

If you're concerned about the long term:

WPF is the way to go. The current / future Windows UI framework is WinRT XAML. It will be MUCH easier to eventually port your WPF app to WinRT XAML than a winforms app. And, since MVVM is really technology-agnostic, you could eventually reuse your ViewModels in ANY other UI technology.

Edit: Since I've been receiving many downvotes and there's a lot of discussion around this answer, I'm going to specifically focus on the OP's question and try to provide a rather objective answer:

Performance: When you compare WPF's memory usage against winforms for really simple UIs (a Window or Form containing only a TextBox for example), WPF seems to consume much more memory than winforms. This is due to the fact that the WPF framework is much larger than winforms and therefore it has many more "things to load" in order to work. This is also true when you compare the cold startup times (again, in a 1-control situation).

In contrast, when you create heavier UIs composed of several controls / Buttons / DataGrids / ComboBoxes / TextBoxes / etc (things that are really common in Business Applications) the difference starts to diminish until it even favors WPF. This is because WPF's DependencyProperty system, which stores default property values in a single memory space rather than in a per-instance basis.

WPF was intended to be used for complex / Rich UIs from the beginning and is optimized to work on situations where there are thousands of controls, rather than the 1-control case.

Another really important aspect to consider when comparing performance between WPF and winforms from a data-centric perspective is, as mentioned above, UI Virtualization. Just by looking at this Video it becomes obvious that WPF performs much better in a situation where you need to display 20k rows in a ListBox. I've been told by a winforms guru that winforms seems to also support that, but you need to resort to called P/Invoke due to winforms not properly supporting that, and from what he said it is not obvious to me if other controls aside from the ListBox also support that in winforms (such as the DataGridView and TreeView). ALL WPF ItemsControls are already or can be made virtual by default with some simple Application-wide Styles.

Hardware Acceleration: you might think "I don't need this", but if you look around, there are thousands of situations where winforms will start flickering horribly when updating the UI, not necessarily in a complex drawing situation, but also when resizing a Window that contains many controls. There are ways to workaround this, but then again, you'd have to start losing time in fixing an issue that you should never have to begin with, instead of concentrating on your Business Logic. You will NEVER have this problem with WPF, not only because it is hardware-accelerated, but also because it is Vector based, rather than Bitmap based.

Conclusion: While winforms may perform better in the 1-control case, WPF is a clear winner at all levels for real-world Datacentric UIs.

Aside from all this, and as mentioned by @Blam, choosing a technology requires that you analyze not only the performance aspects but also the scalability, customizability, maintainability, ease of development, long-term perspective, among many other things.

In all these aspects, WPF is again a clear winner. a well-designed WPF MVVM application has a really clean, concise, beautiful code-base. winforms, no matter how expert you are with it, will always force you into dirty code behind solutions, simply because it doesn't support really complex scenarios and requires custom code for almost everything one can think of.

With customizability in particular, I will say that even if you do not plan to ever create a Completely Custom, Rich UI, choosing WPF is still a much wiser decision, because with winforms, you can eventually hit a wall if you ever want to Display your Data in a format that's not supported by default. Then you will have to start suffering and losing your time with horrible techiques such as "Owner Draw", whereas in WPF all you need is a simple DataTemplate

Granted, WPF is complex framework, but it's not really the complexity of it what makes the steep learning curve, but rather the required Change of Mentality is really what most developers coming from other frameworks struggle with.

And, as mentioned above, it is important that you code against abstractions, rather than against a specific set of classes, so that your code can eventually be ported to other frameworks if ever needed. WPF allows for that, winforms does not.

If you code on winforms, you will be stuck forever in winforms' incapabilities and code behind hacks. It is true that if you use MVP on winforms this is somewhat alleviated, but still the Presenters have a much tighter coupling with the UI framework than ViewModels in MVVM, which are completely UI-agnostic.

If you code in WPF with XAML and MVVM, you can eventually replace the WPF XAML views for something else, and keep your ViewModels untouched, which means that you actually NOT have to rewrite your entire application from scratch, because the ViewModels are the Application, not the Views.

Community
  • 1
  • 1
Federico Berasategui
  • 43,562
  • 11
  • 100
  • 154
  • 18
    As much as I love WPF, I wouldn't say WinForms is useless... It allows for much faster development if you're making simple apps with very simple UI. I still use it when I want to make a "quick and dirty" tool for internal use – Thomas Levesque Oct 28 '13 at 18:46
  • 15
    "Completely useless" doesn't sound like a neutral, well-thought point. Personally I don't trust 100% claims. – Uwe Keim Oct 28 '13 at 18:52
  • 4
    Agreed with Thomas and Uwe. There are preferred patterns and practices for both platforms. The alleged necessity of WPF is as oversold as its promises of high performance (it never quite lived up to them). But it _is_ a rich and capable platform, and if you are not heavily vested in WinForms, I would say WPF is preferable. – Mike Strobel Oct 28 '13 at 18:53
  • 2
    @Thomas "It allows for much faster development if you're making simple apps with very simple UI" How so? WPF has a visual editor with toolbox so you can slap controls on quickly. The time development differences are negligible – jamesSampica Nov 02 '13 at 15:27
  • 1
    @Shoe right. Plus WPF requires almost no code because it has DataBinding, therefore even for simple apps it's much better. – Federico Berasategui Nov 02 '13 at 15:35
  • 2
    @Shoe, yes, WPF has a visual designer, but it sucks so much I never use it. It doesn't take advantage of the WPF layout system, and always uses absolute positioning using margins, which is stupid. Sure, you can change it, but the default positioning is just plain wrong, and it encourages bad practices. – Thomas Levesque Nov 02 '13 at 17:21
  • 1
    @Thomas Yeah it sucks, but were talking about "fast development", remember? Winforms offers you the same crappy visual editor minus the good part (xaml) – jamesSampica Nov 02 '13 at 20:33
  • @Shoe I never looked at things from that perspective. Not that I didn't already know that winforms is useless, but you give me even more arguments to think so. Thanks – Federico Berasategui Nov 02 '13 at 21:59
  • 4
    Useless is as useless does. As a WinForms developer I realize the limitations I have. If the learning curve were not so steep and our apps not on such short time tables, I would most likely be in favor of WPF. However, discussing WPF vs WinForms is akin to discussing C++ vs C#. Both have their place, both have their distinct advantages and disadvantages. To say one is better than another implies subjective arguments throughout. – IAbstract Nov 18 '13 at 21:29
  • @Iabstract except `C++` is really adequate when you need lower-level stuff, which C# might not be suitable for. Whereas there's not a single use case or technical argument to choose winforms, it's just a matter of "learning curve" as you call it. Yes, GW-Basic developers from 50 years ago would probably also have a hard time understanding concepts that a C# developer deals with on a daily basis, however that doesn't make GW-Basic less useless in the present world in 2013. – Federico Berasategui Nov 19 '13 at 01:37
23

There is no meaningful "yes" or "no" answer to this. It depends on many factors, including but certainly not limited to:

  1. What kind of UI you are building.

    Obviously, the complexity of the views you are designing will factor in to performance on both platforms. They have different layout and rendering pipelines.

  2. How effectively you optimize for performance on each platform.

    It is, of course, easy to implement poorly performing UIs with both platforms. Implementing a complex UI such that it performs very well requires knowing how to leverage each platform's strengths and weaknesses effectively.

  3. Whether you are using out-of-the-box controls or third-party controls, and the quality of those controls.

    Items 1 and 2 carry over to any third-party components as well.

If you are an experienced and competent WinForms developer, then you probably already know how to create performant views in WinForms. The learning curve for WPF is steep; any seasoned WPF developer can tell you that. They will also tell you that you can use it to build rich UIs that perform well. That is also true. The same is true for WinForms.

Both platforms are mature. Both are used widely. Neither is likely to see any future improvements apart from bug fixes.

All that said, if you are not already heavily invested in either platform, I would go the WPF route. It's a rich (albeit heavyweight) framework that can be made to perform well. The amount of effort required to make it perform well depends largely on the types of views you are creating, but I have built many high volume, high frequency data views with WPF. I have also built a visually rich strategy game with WPF. But don't feel compelled to go with it; if your developers are already experienced with WinForms, it remains a perfectly viable option.

Update: I think it is unlikely that WinForms support will be removed from .NET in the next few years, but if this is a concern, then I would go for WPF. The types of views you describe can be created in WPF easily enough. For comparison, I have several views capable of displaying 50,000 to 500,000 rows with 60+ columns; thousands of row updates per second; custom, multi-level sorting and grouping applied; custom filtering; custom summaries; all kept up to date in pseudo real time ("human" real time). Getting that level of performance was not easy, but it can be done. The volume and frequency of data you are describing should be considerably easier to achieve with either platform, and using only the built-in control suite.

Mike Strobel
  • 25,075
  • 57
  • 69
  • Thank you for answering. I've updated my question with some more information and a description of what I plan to do with the UI. I'm still designing the software and haven't even finished coding, but I was curious about WPF in general. I have heard concerns of it being possible for WinForms to be dropped at some point within the next 2-3 Windows releases (something like 7-10 years out), so obviously I'm a bit concerned. – mlw4428 Oct 28 '13 at 18:40
12

I tried drawing a large amount of lines on a panel in winforms and the same dt on a canvas in using WPF and found the winforms creted the drwing in less than second, wheres WPF took many seconds, even though I ws using Pathgeometry in WPF rather than shpes

steve konarski
  • 131
  • 1
  • 4
6

I've coded a number of application in MVVM pattern for both Windows Forms and WPF and when you compare the same application implemented on both, windows forms wins for data bound applications. You notice the affect more if you have more than one child datagrid bound to a single parent datagrid or structure, never understood why. So for business applications I always code in WPF only if I have to. I also find sorting and filtering is also easier on windows forms.

Terry Mac
  • 61
  • 1
  • 1
  • Great piece of advice here. I attempted a wpf business app with a number of Datagridviews that were frequently updated by mouse events, and on older production pcs, the app would take as long as a second between mouse click, and ui response. Winforms version response time is practically immediate. – CJ K Jul 26 '20 at 23:49