# .NET and More > WPF, WCF, WF >  A few questions about WPF

## Goshx

1. Is it a good idea to start learning WPF approach in VB.net programming? It is present almost 10 years but I can't say that it is popular between programmers. People continues to work with WinForms although WPF offers better capabilities. 

2. Why WPF projects work slower than WinForms?

3. Should WPF accelerate work with graphics comparing with WinForms' GDI+? In my concrete case I am using a picturebox which accepts large images (10-30mpx) and processing with WinForms/GDI+ is rather slow. That's the main reason why I am thinking about moving to WPF.

----------


## Goshx

141 views, 0 answers. I've expected at least a dozen of answers 

Obviously WPF isn't popular between programmers.

----------


## szlamany

I've used WPF - never noticed "work slower than WinForms".

What do you mean by that?

As for #3 - you can easily test the speed of loading pictures between WinForms and WPF.  If this issue is a deal breaker for you then you should benchmark both.  

I would expect WPF to be faster.

----------


## passel

> ... large images (10-30mpx) and processing with WinForms/GDI+ is rather slow. That's the main reason why I am thinking about moving to WPF.


What do you mean by processing?  What processes are you doing on the images?

----------


## Goshx

> I've used WPF - never noticed "work slower than WinForms".
> 
> What do you mean by that?


When you load some project written for WPF, everything is much slower than when you work with WinForms. Visual studio itself was written in WPF and works slower from that time. I've read that professional programmers who worked with WPF say that it produces slower apps.




> As for #3 - you can easily test the speed of loading pictures between WinForms and WPF.  If this issue is a deal breaker for you then you should benchmark both.  
> 
> I would expect WPF to be faster.


To do that I previously have to learn WPF approach, right? )) By idea it should be faster if it works with hardware acceleration but I couldn't find anything about that. 





> What do you mean by processing?  What processes are you doing on the images?


That means, I'm using ColorMatrix for changing colors, brightness and contrast.

----------


## szlamany

I've used both VS and SSMS - both written in WPF now - and never noticed the WPF platform as slower.

Creating a test app in WPF should require very little learning on your part.

----------


## KGComputers

> Obviously WPF isn't popular between programmers.


- It is popular specifically for programmers using C# as it's core language. 




> 2. Why WPF projects work slower than WinForms?


That was my first impression before when I was working on a WPF project. The causes somehow of our app being slow where coding issues. 

- kgc

----------


## Goshx

> Creating a test app in WPF should require very little learning on your part.


I've seen that it isn't a big problem to move from WinForms. In general, development with WPF reminds me much on programming for Android platform. But... to translate all my code to new platform just to see whether it works faster or not is a bit risky. It is also much harder to find help for WPF than for WinForms. 

If I know that things should work faster, I'd try to convert that form which transform images with ColorMatrix into WPF and integrate it to WinForms project. 

By my opinion, Microsoft made a vrey bad thing disallowing simple integration of WPF inside of a WinForms Project. The same thing is with Mixing of VB.net and C# inside of the same project. Not to mix code inside of the same class but between different modules/forms.

----------


## Goshx

> - It is popular specifically for programmers using C# as it's core language.


Can't see many projects written with WPF although it is already 10 years old  :Smilie: 




> That was my first impression before when I was working on a WPF project. The causes somehow of our app being slow where coding issues. 
> - kgc


Mine too. That's the reason why I put that question.

----------


## szlamany

> By my opinion, Microsoft made a vrey bad thing disallowing simple integration of WPF inside of a WinForms Project. The same thing is with Mixing of VB.net and C# inside of the same project. Not to mix code inside of the same class but between different modules/forms.


I believe the issue is really deeper than you might imagine.  In WPF each control inherits from a dispatcher object which controls threading in a completely different fashion then a WinForm.

So it's not just the XAML which makes it different (which I admit looks like the Android screen layout language).

I also switch to C# when coding WPF - as the book I bought and most threads online seem to be C#.

I would have thought that whatever you do for logic ColorMatrix (whatever that is??) could be tested in a small app in WPF to see how it performs. 

Or are you expecting that your whole app will work sluggish just because you are in WPF??

----------


## passel

There is no ColorMatrix in WPF.
You will have to write pixel shader code (which WPF allows), which will run on the GPU if you have an appropriate graphic card, which should be quite fast in comparison for that specific operation.

Neither GDI+ or WPF were written to be image processors though, so both are unsuited to the task in general. But both do offer some rudimentary image manipulation possibilities, as an aside to their primary purpose (GDI+ for drawing, and WPF for GUI development), so image processing can be done depending on how much code you want to write to make use of the limited capabilities available.

----------


## Goshx

> I believe the issue is really deeper than you might imagine.  In WPF each control inherits from a dispatcher object which controls threading in a completely different fashion then a WinForm.


but we have mechanism to embed WPC into WinForms and vice versa, right? If we already have that possibility they could enable to do that more easy. Although I understand that we have two different concepts of programming's logic. 






> Or are you expecting that your whole app will work sluggish just because you are in WPF??


At thins moment I am just thinking how to fasten image manipulation. One of them is related with WPF. It is just one from from my program. The rest stays on WinForms.

----------


## Goshx

> There is no ColorMatrix in WPF.
> You will have to write pixel shader code (which WPF allows), which will run on the GPU if you have an appropriate graphic card, which should be quite fast in comparison for that specific operation.
> 
> Neither GDI+ or WPF were written to be image processors though, so both are unsuited to the task in general. But both do offer some rudimentary image manipulation possibilities, as an aside to their primary purpose (GDI+ for drawing, and WPF for GUI development), so image processing can be done depending on how much code you want to write to make use of the limited capabilities available.


Thank you for this answer, passel. I couldn't find anything similar with Google. The answer is: you can't process images on the same way as you did with GDI+. Generally, you can, but you have to do complicated things with DirectX subsystem.

----------


## szlamany

> just thinking how to fasten image manipulation. One of them is related with WPF. It is just one from from my program. The rest stays on WinForms.



You should be able to make a library written in WPF that does not do any UI level work - and call that from a Winform app.

Where would the barrier to that be?

This is not my strong area...

----------


## Goshx

I'm afraid that I'll have to forget code translation into WPF ))  if we have to work with pixel shaders (never did that) it isn't a piece of cake.

----------


## Sitten Spynne

Ha, I was going to comment on the age/views/answers ratio myself. Here's my attempts at answers and some comments along the way. 

First, who am I? I'm a veteran of Windows Forms since 2003, and I've been aware of WPF since about 2008. I worked on a major WPF/Silverlight project from about 2010-2012. Currently, I write Xamarin Forms applications, which is a very WPF-like environment for writing applications on iOS/Android/Windows Phone/Windows 10.

1. I think it is foolish to invest several years into Windows Forms at this point. I think a WPF approach is worth studying, but if you're going to learn VB .NET today you should focus about 50/50 on WinForms and UWP. No one's working on WPF desktop applications, but I get the feeling MS is going to force UWP applications on us pretty hard.

2. Lots of reasons. Some of them are "stupid developers". WPF lends itself well to application development frameworks. The ones that auto-configure tend to lean heavily on reflection. That comes with a big startup penalty everyone wants to pretend doesn't exist. WPF uses Object-type variables in a lot of ways I don't like, mostly because MS refuses to switch to their XAML parsers that support generics. That incurs a lot of boxing/unboxing costs.  WPF is more likely to use the GPU than Windows Forms, and most office machines skimp on video cards. And, for image manipulation, there's an entire book that could be written about the hoops one has to jump through because of the lack of immediate mode rendering.

3. This all depends on the definition of 'processing'. IMO, your limitations are likely hard disk speed, RAM, and factors like JPEG compression occupying your CPU.

Comments:



> Obviously WPF isn't popular between programmers.


It's only 10 years old. Something has to be 30+ for a VB developer to try it.




> Visual studio itself was written in WPF and works slower from that time.


This was true for VS 2010 but VS 2012 was vastly improved. The reason there is more or less "There was a huge difference between the first release of WPF and the second, probably motivated by issues MS found by writing VS with WPF." VS 2015 has sort of returned to being terrible, but at this point I don't think it's WPF to blame. 




> It is popular specifically for programmers using C# as it's core language.


Negative. Not even C# developers jumped aboard. And you're only half right: C# is the _.NET_ core language. The bulk of "the industry" uses C#. The thing is, depending on where you look, "the industry" can be very different.




> In general, development with WPF reminds me much on programming for Android platform.


It should. Android's layout system was likely inspired by WPF.




> By my opinion, Microsoft made a vrey bad thing disallowing simple integration of WPF inside of a WinForms Project. The same thing is with Mixing of VB.net and C# inside of the same project. Not to mix code inside of the same class but between different modules/forms.


There's a lot of technical challenges to all of the things you mentioned, and I'd really rather MS spend their time elsewhere. In particular, WinForms and WPF don't get along well in the same process due to WPF being more like DirectX than GDI. For a long time, there were "airspace issues" and if you tried to mix WPF and WinForms in a project, you'd find it impossible to overlap some things. MS addressed that, but it's really best if you don't mix and match.

szlamany's #10 and passel's #11 seem completely accurate, I don't have any comments/corrections.

High-end image manipulation's not something I'm skilled with so I can't comment on how to do it, but considering bitmap operations are essentially array operations I think the problem is .NET, not the particulars of the UI framework. C would be the best bet for high speed, but for all I know pixel shaders might be faster.

----------


## Goshx

> First, who am I? I'm a veteran of Windows Forms since 2003, and I've been aware of WPF since about 2008. I worked on a major WPF/Silverlight project from about 2010-2012. Currently, I write Xamarin Forms applications, which is a very WPF-like environment for writing applications on iOS/Android/Windows Phone/Windows 10.


by my own opinion, you're a generous person always ready to help with your "in depth" explanations.




> No one's working on WPF desktop applications, but I get the feeling MS is going to force UWP applications on us pretty hard.


I'm afraid that is already too late for UWP if we take in account poor success of WP platform. MS aimed to create a bridge between mobile and desktop apps but they failed, I'll say, unfortunately.




> WPF is more likely to use the GPU than Windows Forms, and most office machines skimp on video cards.


I dare to say that today's office machines are quite capable to execute graphic intensive jobs without problems. They have more power in their integrated logic than we had with video cards 10 years ago. What WPF utilize from DirectX capabilities? Nothing especial. Now we can rotate our buttons, add shades and some fancy effects but it is not a hard job for PC machines produced in the last 6-7 years.





> In particular, WinForms and WPF don't get along well in the same process due to WPF being more like DirectX than GDI. For a long time, there were "airspace issues" and if you tried to mix WPF and WinForms in a project, you'd find it impossible to overlap some things. MS addressed that, but it's really best if you don't mix and match.


They could create some kind of interface which enables communication between WPF and WinForms modules. They could allow embedding of WPF inside of WinForms project and on that way make it much more popular. Well. there's a mechanism to embed WPF to WF and vice versa but they could make it much easier to implement. We have two different logic in background but we can join them on some way, 





> High-end image manipulation's not something I'm skilled with so I can't comment on how to do it, but considering bitmap operations are essentially array operations I think the problem is .NET, not the particulars of the UI framework. C would be the best bet for high speed, but for all I know pixel shaders might be faster.


Although WPF exists for 10 years, I could find any literature which explains how to work with DirectX subsystem from WPF. There's no any info how to use hardware acceleration for things different from showing fancy forms' elements. We have a huge processing power inside of graphics cards but we can't use them for things different from 3d video games. Frustrating.

----------


## Sitten Spynne

> I'm afraid that is already too late for UWP if we take in account poor success of WP platform. MS aimed to create a bridge between mobile and desktop apps but they failed, I'll say, unfortunately.


This is part of why I'm not writing Windows applications anymore. If UWP doesn't catch on, I don't believe Windows has a future. And it feels like MS agrees. Visual Studio is the only MS application I can name that hasn't been announced to work on OS X, Linux, iOS, or Android over the past couple of years. If they're not betting on Windows, I don't expect it to stick around.




> I dare to say that today's office machines are quite capable to execute graphic intensive jobs without problems.


You didn't ask about 'possible', you asked about 'slow'. Considering how many office environments are still hovering on Windows XP and Windows 7, I'm not expecting top-of-the-line integrated graphics in client machines.




> They could create some kind of interface which enables communication between WPF and WinForms modules. [...]


The older I get, the more satisfied I find myself looking at answering situations like this with, "If it were easy, they'd have already done it." 

WinForms can't do some things that are expected of modern applications well. Those features cannot be easily patched in, because it's built on top of technology that dates back to when windows were _not allowed to overlap_. There is an immense amount of compatiiblity baggage attached to this, and any change MS makes runs the risk of breaking thousands of ancient-but-mission-critical applications that rely on undocumented behaviors to function. I think MS is very much ready to get away from that albatross, and their message that they'd like people to urgently transition away from WinForms has been clear for almost a decade now. 

Whether or not that's possible or if they've provided the appropriate tools is a discussion for an entirely different thread. But I do think that general idea's sufficient background for the notion that MS believes it would cost them more than it would make them to have interoperable WPF and Windows Forms, even if it were technically possible. 




> Although WPF exists for 10 years, I could find any literature which explains how to work with DirectX subsystem from WPF. There's no any info how to use hardware acceleration for things different from showing fancy forms' elements. We have a huge processing power inside of graphics cards but we can't use them for things different from 3d video games. Frustrating.


That's because WPF itself is focused on client applications, not games. The assumption is if you want to write games you'll use DirectX directly. It is not, and never has been, an attempt to present a .NET interface to DirectX. And, in terms of Windows Forms, I'd be willing to wager money that professional imaging programs like Photoshop do NOT use GDI functions for their image manipulation but instead wrote their own.

It feels to me like whatever you are doing falls outside the parameters of what UI frameworks are best at. You can't spite a hammer for being a poor screwdriver.

----------


## szlamany

I just read up on UWP.  That explains why MS is pushing for Windows 10 upgrades - without wide-spread Windows 10 adoption I cannot - as an ISV - write UWP apps.

@sitten - when you write a UWP app do you have a different version of the .Net framework?

----------


## Sitten Spynne

> I just read up on UWP.  That explains why MS is pushing for Windows 10 upgrades - without wide-spread Windows 10 adoption I cannot - as an ISV - write UWP apps.
> 
> @sitten - when you write a UWP app do you have a different version of the .Net framework?


I guess it boils down to how pedantic you want to be about "different version of the .NET Framework."

If all you care about is, "Will it seem dramatically different from WinForms? Will it be hard to port a non-trivial application?" then yes. MS has promised some kind of bridge to allow 'legacy' apps to run as UWPs. We'll see how well that works when it releases.

To MS, it doesn't seem that confusing. WPF begat Silverlight. Silverlight begat Windows Phone 7. That begat the Windows Phone 8 and Windows 8 application frameworks, which is related to WinRT. Those begat UWP. So for a developer who spent a few hours a year keeping up, everything looks sort of familiar. But to developers who sat in the corner, blinders on, hands over their ears, screaming "YOU CAN'T ABANDON THE DESKTOP", the entire world's upside down, and the best tutorial content's already obsolete. Lots of people wrote a lot of "getting started in WPF", but they don't tend to write "getting started with UWP" because they tend to see it as "like Win8". 

Me, I'm waiting for it to settle. I think a lot of other people are waiting too. I think MS can't make UWP or any other solution very good while people don't use it. But then people don't use it because it's not very good. It's a vicious cycle, and I don't know how Microsoft can solve it short of forcing people to adopt it by pulling the plug on WinForms/API. I don't know if they have the guts, or if it's even the right move.

They certainly can't compete with iOS/Android without a tablet platform. And they can't recoup their R&D in developer tools if that platform isn't using C#. So they just bought a company that makes tools for developing iOS/Android apps with C#. I don't think all their bets are on Windows, today.

But when I survey the field, and look at web, iOS, Android, Mac OS, Windows, and mobile Windows devices, everything looks like WPF and almost nothing looks like Windows Forms. By that I mean: almost everything is using a markup language and data binding for its application framework, and almost nothing is using code-only, event-driven architecture.

----------

