I have tried to improve the performance of a WPF application. I found when the window is minimized, the CPU usage will reduce to 0 or very little usage, but when the application display in the front end, the CPU usage will increase to 10% or more. Anyone know why?
This happens on all WPF apps. When an app is minimised and the UI is hidden the WPF app is not having to do much unless you have tasks running on a background thread.
WPF can be quite resource intensive and there is a cost to drawing windows and controls. If there is nothing happening in the background of the app and it no longer has to draw any windows/controls then the CPU usage will likely be zero.
Related
Suppose I have a DirectX game running in full screen and a WPF application running in the background; in addition, the CPU isn't at high levels, and the game's frame rate is good (i.e., 60 FPS).
Is there anything that might cause the WPF application to render itself slowly? (i.e., at 3-5 FPS)
Wikipedia says: "Rather than relying on the older GDI subsystem, WPF utilizes DirectX."
Therefore, my conclusion is that, if DirectX is busy rendering the game, and the graphic card pipelines are full, the WPF application will probably have poor performance. But admittedly I have no knowledge of the prioritization that goes on behind the scenes, but I'm guessing that a background (that is, non active) window will have less priority.
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'm using the FluidKit Cube Animation in my WPF application.
The animation is smooth when the application window is not in full-screen, but when the application is running in full screen (maximised - borderless window with no controls), the animation is not smooth.
I noticed the WPF application is hammering a single thread and only utilising one of the four cores of the CPU, memory utilisatio is low.
I'm wondering if there is any way of making the window multithreaded or just the animations multithreaded so the application can utilise more of the available hardware?
Are there any other ways to improve animations?
Ben
I will be really excited if someone tells me a UI thread in WPF can leverage multi core CPUs....
Jokes apart, GPU and CPU are different concepts sadly. Will it be controversial if I say "The hardware acceleration mode for WPF apps utilizes GPU's own hyper threading model instead of multi core CPUs."?
Although there are ways to improve animations such as animating Adorners using PresentationSource, Transforming Drawings and Geometries than Shapes, CompositionTarget.Rendering event, BeginStoryBoard.HandoffBehavior="Compose" etc. You will find all of these discussed in details over the internet.
Interestingly there is an old (very useful post) about multi core systems and their impact on parallel .Net frameworks such as PLINQ and WPF 3.0 etc. http://social.msdn.microsoft.com/forums/en-US/wpf/thread/07562a10-17bd-44d3-975b-99ed02bd05de/
I hope this kicks off some very interesting brain storming from our very able StackOverflow experts....
Expectantly Waiting ... :-)
Try to avoid any effects and see how it works and totally avoid bitmap effects, because they force WPF to use software rendering which is not really good.
Suggest you to check out Performance Profiling Tools from Windows SDK. Good luck ;)
I'm drawing an xna project on a winforms Control using the following code:
this.GraphicsDevice.Present(MainForm.GamePanelHandle);
This winforms control is placed on a Form that is maximized, hiding the taskbar using the following code:
this.FormBorderStyle = FormBorderStyle.None;
this.WindowState = FormWindowState.Maximized;
Unfortunately this makes the xna code run choppily as opposed to letting xna create its own window and setting it fullscreen. As I understand this is because the graphics card needs to pay attention to the whole windowing system and other active forms.
Are there any tricks I could use to make xna run faster when embedded on a fullscreen winforms Form?
Have you tried setting:
DoubleBuffered = true;
in your form's load handler ?
This will at least help out with the Form's painting. i'm not sure if it will have an effect on the XNA stuff but it's worth a try.
If you're displaying a maximized form and even hiding the taskbar, why not go to true fullscreen mode? What are you gaining by using windowed mode that just looks like fullscreen? You are certainly reducing yur framerate by doing this.
In my experience windowed mode works best when your window (XNA control) is just a smaller part of the overall form. This is really the point of windowed mode since it allows you to interact with other standard form controls at the same time.
Going to fullscreen mode gives your application exclusive access to the video framebuffer
and avoids overhead of dealing with windows GDI / GDI+ in windowed mode.
Also, if you're using an integrated graphics card (ie. less powerful) you'll need every GPU and CPU processing cycle you can get.
If you absolutely have to stick to windowed mode, I've found that the smaller the window, the better the performance. In windowed mode, reducing the window size has as big an impact on framerate as reducing the complexity of the scene being displayed does.
You could also consider setting the process priority of your application to AboveNormal or possibly even High. Be aware that doing this will cause other applications to respond more slowly while your application is running. To avoid system instability it is also recommended avoid using RealTime.
In .NET this can be done using the Process.PriorityClass property on a process:
// Set the current application (process) priority to high.
Process.GetCurrentProcess().PriorityClass = ProcessPriorityClass.High;
I'm in a situation that requires many animations with effects like transparency to be applied but when there are about 10 of them running, my application slows down to a grinding halt! :(
I also, tried implementing a particle like effect using a frame by frame manual animation using the CompositionTarget.Rendering event, which changed an Image's Source property at a given framerate. Again, this works fine for the first few instances of the particles on the screen, but when more and more get added I need it to stay performance wise, which is always a tough ask for any application
I was wondering if anyone has any experience using pixel shaders in WPF for animations, or perhaps custom writeablebitmap's for animations?
I basically need to palm off most of the animation processing to the GPU if possible...
Thanks for any help you can give!
Cheers,
Mark
If you want performance you should think about using XNA instead.
Then, you can add the XNA project into your WPF app