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.
Related
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.
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.
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;
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,