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
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'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 looking for an Image control for WPF which can rapidly change images. The built in WPF one is quite slow for the image sizes im using (scaled). I only need about ~3 FPS. I have considered dropping to WinForms and even D3D but I'm not sure thats the best way.
Can anyone suggest something?
WPF's Image control uses the native "Windows Imaging" and Direct3D subsystems of Windows to do all its dirty work, so if used with the right paremeters it will be pretty much as fast as anything you will find.
I suspect the problem is that your settings are causing Windows Imaging load the image at full resolution, then having Direct3D scale it. The solution to this is to do the scaling as you load the image by setting DecodePixelHeight and DecodePixelWidth on the BitmapImage you are using as an ImageSource.
Another technique that many graphics apps use to speed things up is to preload the images in the background. For example, the Windows picture viewer automatically starts loading the next image as soon as the current image is shown.
If you are preloading images, consider doing it in a separate thread. Also make sure you use BitmapCacheOption.OnLoad when you create the BitmapImage or the preloading won't actually occur (the default is OnDemand).
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,
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".