I've put off WPF development for a quite a while but, I'm finally thinking of moving ahead. I understand that WPF is totally new rendering "mechanism" which uses the GPU power (am I right?) unlike the CPU power that Winforms took up. If I'm not mistaking, this level of GPU support comes with Aero and therefore, a WPF app should run at full performance only in a Aero environment. Is this correct?
I mean, if I run a WPF (with lots of animations and glass) it will not run as well on a Win 7 Home Basic or XP, would it?
WPF use DirectX as renderer, it isn't related to Aero. It works hardware accelerated on Windows XP too.
As long as the GPU on the machine is fast enough it will run all the effects you want.
Related
In earlier versions of WPF setting Window.AllowsTransparency or using BitmapEffects (the deprecated ones), or TileBrush usage, apparently could cause WPF to switch to a software rendering mode instead of hardware rendering thus affecting performance dramatically.
I found this list, but it is from 2010.
Are there any potentially common cases that could cause software rendering to occur in framework 4+? Assume the hardware is sufficient, purely software related.
This list is still accurate.
This is covered on MSDN's page regarding Graphics Rendering Tiers. The second labeled as "The following features and capabilities are not hardware accelerated:" lists the specific criteria that can cause non-accellerated rendering in WPF.
This includes:
TileBrush
Content rendered via RenderTargetBitmap
Any printed output
Surfaces exceeding the graphics hardware's maximum texture size
Layered windows on Windows XP.
The following blog post by Dwayne Need seems to suggest that layered windows on Windows XP now are hardware accelerated.
http://blogs.msdn.com/b/dwayneneed/archive/2008/09/08/transparent-windows-in-wpf.aspx
DirectX does provide the IDirect3DSurface9::GetDC method, which can
return a DC that references the DirectX surface. Unfortunately there
was a restriction in DX9c that would fail this method if it were
called on a surface that contained an alpha channel. Of course, the
entire point of our layered window API is to enable per-pixel
transparency. This restriction was lifted for Vista, but our initial
release forced WPF to use its software rendering fallback with
rendering to a layered window on XP. We were able to lift this
restriction for XP too, which we released as a hot fix (KB 937106).
This hot fix was also included in XP SP3, so go get it! Now, on XP,
we can render via DirectX and pass the results of
IDirect3DSurface9::GetDC directly to UpdateLayeredWindow. On good
video drivers, the resulting copy will remain entirely on the video
card, leading to excellent performance. Some video drivers, however,
may choose to perform this copy through system memory. The
performance on such systems will not be nearly as good, but should
still be reasonable for many scenarios.
I tested this out by running the Perforator tool of the WPF Performance Suite (and checking the check box titled 'Draw software rendering with a purple tint') ... on a layered window application ... and everything seemed to be hardware accelerated (no purple tinting).
The recent MSDN documentation on Graphics Rendering Tiers still says (as Reed Copsey points out) that it should be software rendered, but that is not what I'm experiencing.
I am working on a WPF application. During tests I noticed, that the application runs way smoother, if I switch to a Windows Aero Theme instead of a Basic Theme.
Why does this happen - and how can I make sure that the applications always runs as smooth as it does when using a Windows Aero Theme?
Thank you for your answer!
The reason might be that Windows uses the graphics card to accelerate drawing processes in the Aero theme.
Therefore, if you deactivate the Aero theme, all the processing is done by the CPU (instead of the GPU), resulting in a degraded performance compared to the hardware-accelerated task (if done by the GPU). The non-Aero theme uses only the CPU for drawing processes!
The source for my claim can be found here
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 have developed a GUI for a random application using WPF. I have a bunch of out of box WPF controls laid on the application window. I haven't customized anything, didn't use bitmaps, etc.
When running my application and zooming using Magnifier application in Windows 7 (Win key + Plus key, the magnified GUI is showing pixels.I am probably wrong, because I can't explain it otherwise, but isn't WPF supposed to provide vector like control rendering?
Thanks for participating in the discussion.
Bonus Reading
Tim Sneath: Magnifier: An Interesting Discovery (archive)
WPF Vector based interface *(screenshot of WPF being vector scaled by Magnifier)
MSDN Blogs: Greg Schechter explains why it longer happens (archive)
Back when Vista first shipped, and when WPF was on version 3.0, zooming with the built-in magnifier would actually do vector-based scaling.
This stopped working when WPF 3.5 service pack 1 shipped. (It worked in 3.5 before sp1.) The reason it worked before then is that the DWM (Desktop Window Manager) - the part of Windows responsible for presenting everything you see on screen - uses MILCORE.DLL to do its rendering. Version 3.0 and 3.5 of WPF also used this same component to render - this meant that all WPF content was native content, so to speak. (In fact, on Windows XP, which doesn't have the DWM, MILCORE.DLL is something that WPF puts on your system for its own benefit. But it's built into Vista and Windows 7.) When WPF was using MILCORE.DLL to render on Vista, any effects applied by the DWM such as scaling would also apply in the way you want to WPF - it really did scale without pixelating.
Unfortunately, this is no longer the case. And the reason is that WPF started adding new rendering features. In 3.5 sp1, the new feature in question was support for custom pixel shaders. To enable that, Microsoft had to release an update to the MIL. (The Media Integration Layer - the bit that does the actual rendering.) However, they weren't really in a position to update MILCORE.DLL, because that's part of Windows - it's how everything you see on screen gets to be on screen. Releasing a new version of MILCORE.DLL effectively means pushing out an update to Windows. The release schedule for Windows is independent of that for .NET, and so the only way the WPF team could reasonably add new features was to ship a new MIL. (In theory they could have done it via Windows Update, but since WPF is now owned by a different division of Microsoft than Windows, that sort of thing doesn't seem to happen in practice.)
As of .NET 3.5 sp1, the MIL is in a different DLL called wpf_gfx_vXXXX.dll where vXXXX is the version number. In .NET 4.0, it's wpf_gfx_v0400.dll.
The upside is that WPF gets to add new rendering features with each new version, without needing Windows itself to be updated. The downside is that WPF's rendering is no longer as tightly integrated with Windows as it was briefly back when Vista shipped. And the upshot is, as you've seen, that magnifying is not as much fun as it used to be.
The magnifier application implements its own zoomed image rendering, so that's why you are seeing pixels. WPF does use vector graphics, but in this situation it's not the WPF application itself that is rendering the zoomed image.
If you use something like Snoop you can see zoomed and scaled WPF vector graphics rendering in action.
I suppose, Windows 7 magnifier takes a snapshot of actual application on-screen UI, and then magnifies it itself (not making a special case for WPF applications). Of course what it can access is just the pixels, not the vector graphics which works behind the scene.
The Windows-7-Magnifier is pixel based, but there is a difference in magnifier mode depending on wether an Aero-theme is active or not.
with Areo theme the zoom is pixelated.
without Areo theme the zoom is smoothed (blurry).
Only with Areo theme other Views (except "Docked") are selectable.
I'd like to draw a high-framerate (30fps+) graph/chart in a Windows Forms app.
How?
Windows Forms gets TERRIBLE frame rates drawing a clear-background drawing over a window.
(I come from the land of GNU, so I apologize if this is obvious.)
If you're using Windows Forms (as said in your question):
If you need to get >30FPS, you'll probably need to change to a different technology. GDI+ drawing is not too efficient.
DirectX would work well for this. You can do the charting in Direct3D using DirectX embedded in a Window. SlimDX is a good way to do this from C#.
That being said, you tagged this with WPF - if you're using WPF, everything is retained mode graphics, so there should be no "clear-background drawing" required. You would just put in the chart elements as needed. In that case, 30FPS should be doable.
Running full tilt I get about 180FPS using a System::Windows::Forms::DataVisualization::Charting::Chart plotting 128bins of an FFT using a 'FastLine' style for the series of data. That's running on an Intel Core 2 Duo (2.53Ghz) IBM Thinkpad.