After reading the wikipedia article on WPF architecture, I am a bit confused with the benefits that WPF will offer me. (wikipedia is not a good research reference, but i found it useful). I have some questions
1) WPF uses d3d surfaces to render. However, the scenegraph is rendered into the d3d surface by the media integrated layer, which runs on the CPU. Is this true ?
2) I just found out by asking a question here that bitmaps dont use native resources. Does this mean that if i use alot of images, the MIL will copy each when rendering, rather than storing the bitmaps on the video card as a texture ?
3) The article mentions that WPF uses the painters algorithm which is back to front. Thats painfully slow. Is there any rational why WPF omits using Z-buffering and rendering front to back ? I am guessing its because the simplest way to handle transparency, but it seems weak.
The reason i ask is that i am thinking it wont be wise for me to put hundreds of buttons on a screen even though my colleagues are saying its directx accelerated. I dont quite believe that whole directx accelerated bit about WPF. I used to work on video games and my memory of writing d3d and opengl code tells me to be cautious.
For questions #1 and #3 you might want to check out this section of the SDK that discusses the Visual class and how it's rendering instructions are exchanged between the higher level framework and the media integration layer (MIL). It also discusses why the painters algorithm is used.
For #2, no that is most definitely not the case. The bitmap data will be moved to the hardware and cached there.
I tested that, I wrote two programs that show 1,000 buttons on screen, one in WinForms and one in WPF, both worked just fine.
I then pushed that up to 10,000 buttons, at that point the WPF app took a few seconds to start but run just fine, the WinForms app didn't start.
Win32 itself (and WinForms) isn't built for applications with hundreds of controls (believe me I wrote such an app), at some point it just stops working, WPF on the other hand, keeps working even if it slows down a bit at some point.
So, if you do need to put a lot of controls on screen WPF is your best bet (unless you want to roll your own UI framework - and you think you can do better than the entire MS perf team).
Also, WPF has many advantages other than graphics acceleration: richer graphics, drawing model that is easier to work with, animations, 3d and my personal favorite - amazing data-binding.
This will let you develop richer UIs faster - and I think that will make a much bigger difference than the painting algorithm used.
BTW, if you need to put hundreds of buttons on the screen this is likely to be a bad user experience and you may want to reconsider your UI design,
Related
In our WPF application, we have a need to display about 64 real-time level meters for an audio application. The tests we've thrown at WPF, even when rendering basic primitives as efficiently as we can still show it to be nowhere near where our application needs to be, often times bogging down the main thread so much to the point that it's non-responsive to input.
As such, we have to go with something more optimized for graphics performance such as DirectX (via SlimDX or SharpDX) or OpenGL/ES (via Atlas which converts it to DirectX calls.)
My question is if it's possible to create multiple, small DirectX-based areas, each representing an individual meter, or for that matter, is that even the right approach? I was under the understanding that you have to run it as at a minimum, the entire window, not a portion thereof.
The issues I see with the latter are airspace issues wherein you can't have WPF content in front of DirectX content in the same window, and we really don't want to have to redo all of our controls in DirectX since for the other non-meter 95% of our UI WPF is great!
I have read that you can render DirectX to a brush, then use that inside WPF, or using the WriteableBitmap class which gives you direct access to the buffers WPF then uses in its Render thread, both of which don't seem to suffer from the Airspace issues, but that seems we'd be right back at the same place with WPF being the bottleneck since it still has to do the rendering.
We are of course going to dedicate a few weeks to sample applications testing all of the above, but I'm wondering if I'm even headed in the right direction, and/or if there are any caveats we can avoid by talking to people with experience doing something like this to avoid common pitfalls, etc. As such, any comments will be appreciated.
I'm hoping we can perhaps even start a wiki somewhere to discuss this topic as it seems to be a popular one, albeit spread all over the place making it hard for new entrants to get the information they seek.
With wpf / d3d interop, You should always try to create the smallest number of interop calls. So you should prefer rendering all 64 level meters in a single render target (also it allows you to batch your primitive rendering and draw everything in the smallest number of gpu calls).
you should try to use the D3DImage API that allows you to share your own D3D texture with the wpf renderer.
If WPF can't really handle these 64 moving bars, you could go with a single D3DImage and use Direct3D9 for rendering all bars at once directly to it. For your specific scenario, you shouldn't have any performance problem.
I am about to begin a new project. Some decisions are out of my control: Using WPF and OpenGL are some of them.
However, I have narrowed down my OpenGL options to two: Either OpenTK or SharpGL. SharpGL has a WPF control, while OpenTK only has a Windows Forms control, which makes it that I have to embed it in a Windows Forms Host :-/
While I don't mind the airspace restrictions, I do wish to have decent performance, since I am building a real time application. Not a game, but still, real time.
How much of a performance hit would my program take for using OpenTK over a Windows Forms Host, vs using SharpGL with a "pure" WPF control?
When it comes to performance, I can actually only give you a single answer: Do a benchmark yourself! But as you are asking for an elaborate guess:
SharpGl should require an indirection step less, as it leaves out the Windows Forms host control as an "intermediate" blitting target. Take this with a grain of salt though, I have neither looked at the source nor tested it myself.
But practically speaking: The performance should be very similar. At the end of the day the computational heavy operations will probably be the rendering itself, which is done by OpenGL. Blitting the finished result should only take a fraction of that time. So I hope that, however you decide, none of these options would really hurt your performance.
For the sake of the argument: Lets assume the rendering itself (the OpenGL part) takes 16 ms, so we would have a theoretical perfomance of about 60 FPS. Framework A adds an overhead of 1 ms, Framework B an overhead of 4 ms. Even with this quite gross difference in the overhead, Framework a would render at ~ 58 FPS and Framework B at ~ 50 FPS. So in both cases, the application should remain usable.
But what puzzles me is how much you are wondering about this aspect. In the end you are doing work with OpenGL and it shouldn't be too much of a hassle to simply switch the underlying implementation in case things go bad? The interfaces don't seem too different to me.
I would say go with OpenTK, or if it's more comfortable for you to use SharpGL, then go with it in Winforms mode and embed it inside a WPF application.
The reason is that the OpenGL driver knows how to work with a window handle, provided with every winforms control. In a WPF application there is only one window handle, the one of the main window. You may try to use it, but I think it will pose too many problems.
If you don't want things to get rendered directly to screen, and you think of using a PixelBufferObject or a RenderBufferObject, than you will probably be okay with SharpGL in WPF mode (it renders to a RenderBufferObject, than places the resulting buffer in an image, probably using a WritableBitmap or so), or you can do the same thing yourself.
As far as I know WPF applications should work faster than Windows Forms applications because WPF applications use DirectX for rendering instead of GDI. But what kind of application will start faster: WPF or Windows Forms? Will the start time be roughly the same or will one type of application be considerably faster than the other?
I am not targeting any specific operating system.
Just to point out, in my experience the WPF renderer is in fact quite a bit slower than Windows Forms, despite using DirectX. This is because lots of tesselation and layout calculations are done on the CPU side, which effectively cancels out the performance gain of using the GPU.
Just google around for "WPF Slow" or "WPF Performance" and you'll find horrified developers shocked to learn their time and effort spent converting WinForms to WPF because of spin about GPUs has been wasted, as the result is slower than the original application.
However ... I will say this. WPF is far superior to WindowsForms in terms of styling, graphical capabilities, developer productivity (databinding), animation, look and feel etc. If performance really is an issue, on certain areas you can optimise. For instance, did you know that you can get an API to write directly to bitmap in WPF (see the WriteableBitmap class) to do GDI-like operations in memory? This is (surprisingly) about 20x faster than the WPF primitives for some operations.
Similarly you can use virtualization to improve the performance of datagrids etc. Telerik have an example of their grid scrolling 1,000,000 rows at interactive framerates.
In conclusion, have a think about what you are doing and see similar examples on the web. Are you doing real-time scientific dataacquisition and visualization or just a standard line of business app? Comparing similar examples to see what the framework is capable of will help you in your decision.
Update 2013 Q3
As an update, in various projects I'm now seeing faster and faster performance from WPF by moving anything and everything off the UI thread. E.g. leave the UI thread just for UI, do as much work as possible using Task Parallel Library or RX. Make everything async and don't block the UI thread while waiting.
Eliminate binding errors as these contribute to WPF performance problems.
You can move animations (e.g. wait or loading animations) onto a different thread for glitch-free animation. You can use render-to-bitmap when doing animated transitions.
The long story short? It is possible to get great performance from WPF applications (as well as slick UI) but you need to put in a bit more work!
I think the start time will be about the same.. I have created a few WPF applications recently and in some cases I think the initial loadtime is a bit slower than win forms, but it is not much and WPF more than makes up for it when the application is up and running
From my experience, I think WPF is quite reactive at start compared to winforms. However, the question is tough, especially considering that WPF can contain the other and vice versa.
I'd follow the philosophy of this article : http://joshsmithonwpf.wordpress.com/2007/09/05/wpf-vs-windows-forms/
WPF and Winforms are just not the same tool, and neither of them is supposed to substitute for the other ;)
The question has a lot of duplicates on this forum, please check here for a link and discussion and all of them : WPF vs. Windows Forms
I am programming simple Windows apps. I don't need DB support. Why would I use WPF instead of WinForms?
One obvious answer is that WPF offers a richer user experience than WinForms, allowing for animations (even 3D) in the user interface, for example.
From a development perspective, it goes a long way to enforce the separation of the User Interface (in the XAML) from the business logic (in VB.NET or C#), which is always a good thing.
A Google search for "WPF vs WinForms" brings up lots of pages that discuss this issue. I won't repeat all their findings here, but this page raises some interesting points:
Databinding in WPF is superior to what Windows Forms offers.
UI and C# business logic can be cleanly separated in WPF
Storyboard
Data/control templates – a much cleaner way than anything Windows
Forms can offer.
Styles – cool and simple. Its so easy to style all your buttons in an
application to have the same look and
feel.
Even if the VS designer breaks, its easy to code XAML.
UI virtualization – I’ve got grids with 100K rows, ticking off a moving
market. Performance would be dreadful
if it wasn’t for UI visualization
which come for free.
3D support.
Nothing scientific but, UI development feels quicker in WPF –
maybe its just because a WPF
application looks cooler at the end of
an iteration, or maybe its because
development really is quicker.
I can add a User Experience engineer to my team, and with no C#
knowledge he can work magic in
Expression Blend and give the
front-office trading application a
makeover that is guaranteed to win
over the business users.
WPF is the current platform for developing Windows desktop applications. It is a modern, advanced, hardware accelerated framework for developing applications that maintain separation of concerns. It supports advanced rendering of 2D vector and 3D graphics, providing an immense range of capabilities for building rich, interactive, and quality user interfaces.
WinForms, on the other hand, provides a basic platform for developing "classic" Windows apps with your standard look and feel using standard controls. It does not offer the rich, hardware accelerated, vector 2D and 3D capabilities that WPF offers. WinForms applications tend to have much greater coupling between application behavior and UI (view), which presents a less flexible platform upon which to develop applications.
As for which one you choose, it entirely depends on your needs. If you need vector graphics, 3D rendering, the ability to create rich, interactive, animated, modern user interfaces, and/or wish to maintain separation of concerns, WPF is definitely the right choice. If you need none of that, and just need to create a simple UI that solves a simple problem, WinForms will meet your needs just fine.
To learn.
To have greater (i.e. any) control over the appearance of your program
To benefit from easier data binding, triggers, styles
(I don't see what DB support has got to do with it)
WPF can utilize hardware acceleration to some degree, but that is expected to improve over time.
Also, because of XAML, you have more options for "doing stuff", declarative vs. programmatic, or a mixture of both.
Microsoft no longer does active development on WinForms, they are strongly pushing WPF, and for good reason.
WPF allows for much easier "resolution agnostic" designing. To achieve that in WinForms, it is a lot more work.
The MVVM pattern was already mentioned in one of the comments, this allows one to do real unit testing vs. GUI-based testing on your code, that is a big win, in my experience.
Nobody mentioned about better testing capabilities of the WPF applications (if they are written in the correct way, for example based on the MVVM pattern).
A
Anywhere Execution due to XAML.
Can be used as WinApp, WebApp, Mobile.
Whereas WindowsForm Internal UI representation is in C#.
B
Binding -->Simple object to object data transfer.
C
Common look and feel(Styles) -->can define look and feel styles commonly and use it for bunch of controls.
D
Directive Programming -->Binding objects in XAML.
E
Expression blend and Animation-->WPF uses DirectX, and DirectX can be used for animation.
F
Faster Execution(Hardware Rendering)
WPF internally uses DirectX (Hardware rendering) while Winform internally uses GDI (mostly uses Software rendering).
There are two ways by which a computer renders display on monitor.
1) (CPU) Software rendering -->In case of CPU rendering ,the CPU drives the whole logic of rendering display on monitor.CPU also does other operations like running applications,performing memory management,running OS. So on top of it its extra load to display things on monitor.
2)(GPU) Hardware rendering -->Its Specialized kinda processor, specifically meant for rendering and display faster on monitor.
Now in WPF, this rendering is further optimised in
>Tier 0 mode (Software rendering) uses DirectX7 internally,
>Tier 1 mode (Partial Hardware rendering) uses DirectX7 to DirectX9 internally,
>Tier 2 mode (Hardware rendering) uses DirectX9 internally.
G
Graphic Independence (DIP) -->Means resolution independence
Resolution --> Total number of pixels that fits into screen/monitor
Pixel --> Simple dot on screen.
Windows form uses pixels as a measurement unit, so when pixel changes then win forms has to adjust itself that means we have to write logic for it.
But WPF does not use pixels as a measurement unit but uses DIP(Device independent pixels)
1 DIP = 1/96th of the inch.
At last Testing --> Better unit testing with use of MVVM pattern.
If you want to have a rich user interface like the image posted in your previous question, I'd recommend going with WPF. Aside from making it easier to create a nice-looking application, it's also the technology Microsoft will push in the future. There's almost no new development for Winforms.
The single most important difference between WinForms and WPF is the fact that while WinForms is simply a layer on top of the standard Windows controls (e.g. a TextBox), WPF is built from scratch and doesn't rely on standard Windows controls in almost all situations.
A great example of this is a button with an image and text on it. This is not a standard Windows control, so WinForms doesn't offer you this possibility out of the box. Instead, you will have to draw the image yourself, implement your own button that supports images or use a 3rd party control. With WPF, a button can contain anything because it's essentially a border with content and various states (e.g. untouched, hovered, pressed).
check this article it will help you:
https://www.wpf-tutorial.com/about-wpf/wpf-vs-winforms/#:~:text=The%20single%20most%20important%20difference,controls%20in%20almost%20all%20situations.
I love programming with and for Windows Presentation Framework. Mostly I write browser-like apps using WPF and XAML.
But what really annoys me is the slowness of WPF. A simple page with only a few controls loads fast enough, but as soon as a page is a teeny weeny bit more complex, like containing a lot of data entry fields, one or two tab controls, and stuff, it gets painful.
Loading of such a page can take more than one second. Seconds, indeed, especially on not so fast computers (read: the customers computers) it can take ages.
Same with changing values on the page. Everything about the WPF UI is somehow sluggy.
This is so mean! They give me this beautiful framework, but make it so excruciatingly slow so I'll have to apologize to our customers all the time!
My Question:
How do you speed up WPF?
How do you profile bottlenecks?
How do you deal with the slowness?
Since this seems to be an universal problem with WPF, I'm looking for general advice, useful for many situations and problems.
Some other related questions:
What tools do you use for WPF development
Tools to develop WPF or Silverlight applications
How do you speed up WPF?
Often after using one of the following profiling tools it is obvious what is causing my bottlenecks.
If memory is the issue then I virtualize my data.
If render time is the issue then I virtualize the controls or simplify control templates where possible.
If processing time is the issue I try to improve my algorithm or move that work to a background thread and show a throbber in my ui while the work is going.
How do you profile bottlenecks?
.NET Memory Pofiler
dotTrace
Performance Profiling Tools for WPF
Snoop
Crack.NET
How do you deal with the slowness?
Profiling and counseling.
Install SP1... Loads of very cool performance increases for WPF!!!
Read more here
Here is a example of 2 enhanchements made in SP1: Deffered scrolling & UI Element recyceling!!!
I can not add comments, that's why I post a new answer to this: I've found this video from the pdc09 that gives some ideas about how to profile wpf apps and because it helped me lot, I want to share the link:
Advanced WPF Application Performance Tuning and Analysis
WPF is meant for computers with modern graphics cards. Do your clients have modern graphics cards capable of running Aero? If your clients have older graphics cards, WPF will fall back to software rendering which runs extremely slow in comparison to hardware accelerated graphics.
You also might want to profile your application to make sure that it is actually WPF that is the slow part. It's possible that there is something else that is actually the bottleneck.
avoiding animations also helps a lot sometimes. if you have to use animations, decrease the framerate, this will improve "Feeled" performance
Remove alpha transparency/ bitmap effects.
can you give more details?
I only noticed a slow performance when I use something like a listview or a grid that has some complexity. The solution is to simplify it.
Other than that I only noticed a slow performance when loading the app for the first time.
HTH
I find it helpful to side-step the XAML, and write the entire UI in C#. This lets me precisely control when the controls are created and loaded. It also helps me understand what XAML is doing "under the covers".