tags:

views:

2823

answers:

3

Since XAML gets compiled, there should be no difference in execution of code like this.
Winforms (code like):

Form formPeter = new Form();
Textbox textbox = new Textbox();
Label l1 = new Label1();

Xaml does not get parsed at runtime, as I thought... :-)

But what about rendering/execution of big forms with lot of controls? Which technology is faster?

+3  A: 

WPF uses DirectX for rendering (which is much faster) instead of the native Windows GDI.

As you might already know, Native GDI is bitmap based. As WPF is vector based, WPF can make use of hardware support, in a much better way when compared to GDI.

How ever, the decision to choose WPF or Winforms heavily depends on other factors as well - The flexibility you need in the UI, how much media support your application needs etc. WPF is not a replacement for a Winforms - and it is not a silver bullet for all the problems.

With more hardware acceleration features coming up, WPF can deliver much better than your Winform applications.

A couple of interesting blogs I read ealier.

John's Post

Rob's Post

amazedsaint
+12  A: 

Which Technology is faster? I'm afraid your question doesn't really have a simple answer.

Your comment about XAML not being parsed at runtime is both true and false. While the XAML is not parsed a normalized binary version of it (embedded as a resource in your application) called BAML is parsed at runtime. To say DirectX is faster than GDI is also something of a simplification - WPF and GDI-based rendering technologies just have different performance characteristics. For example WPF uses a retained rendering mode, whereas WinForms and other GDI-based technologies do not. WPF objects tend to be much heavier-weight because they support many many many more properties than their winforms counterparts. We have decades of knowledge on how to make GDI go pretty fast, and only a relatively short time with WPF and XAML.

WPF is sufficiently fast for writing applications, but you need to be constantly vigilant that your element count doesn't blow out (by creating overly complicated templates for example, and then having them repeated hundreds or thousands of times in your UI). Also WPF performs differently on different graphics hardware (since it calls down to DirectX internally). 2D content should be fine in WPF, even if it is totally rendered in software (say the way it would on a virtual machine) but animated, anti-aliased 3D with lots of elements requires real GPU power. As time moves on and graphics hardware becomes more powerful and prevalent and knowledge about how to performance-tune WPF improves we should see WPF pull further ahead (assuming it is slightly so now...for some scenarios...sometimes). So I guess the answer is "it depends".

Joseph Cooney
I'd say WPF objects tend to be lighter-weight due to WPF's sparse storage infrastructure. Dependency property values are only stored if they vary from their default value, so huge savings on memory are made.
Kent Boogaart
I'm curious and a bit pessimistic about performance on terminal server.
Guge
As well you should be, Guge. WPF sends graphics rather than primitive commands or tokens representing controls. AFAIK, Microsoft have not committed to doing anything to fix this situation, either.
Kent Boogaart
+1  A: 

WPF drawing is much faster, but objects are heavier. If you throw in 1000 separate buttons, it will be crawling. On the other hand, those buttons can have complex transparency and gradients without significant performance hit.

ima