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
Related
I am a bit confused about per-monitor dpi-aware in WPF. I thought you need to do some work to make your windows scale properly on different monitors (as described in Developing a Per-Monitor DPI-Aware WPF Application).
But I've just ran my app on pc with two monitors (2560x1440 and 2160x1440) and the dialogue would automatically scale itself when I move it between monitors. That's on the latest fast ring Windows 10. Am I missing something?
What you see is an example of System scaling when one app window moves to a different monitor with a different DPI. That is because WPF apps are by-default System DPI Aware. As a result, if you notice carefully, you'll see WPF visuals/text gets blurred when the target DPI is higher or they look fuzzy when the target DPI is lower.
Also, note that monitor resolution does not matter for WPF apps, since WPF is device resolution agnostic (it's measurement unit is Device independent Pixels).
Good news : .NET 4.6.2 preview just got released and it hasPer Monitor DPI Awareness out of the box. Check out the developer guide and samples here :
https://github.com/Microsoft/WPF-Samples/tree/master/PerMonitorDPI
Continuing the conversation from comments.
Yes that is the same for Windows 8.1.
And here is the note from your linked post
Windows Presentation Foundation (WPF) applications are by default system DPI-aware.
HTH
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'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'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.
I am relatively new in the WPF world and one thing I immediately noticed is how laggy the window content is drawn when you resize a window. For example if you have scrollbars at the window edges those scrollbars will be partly hidden while shrinking and have space between them and the window border when enlarging.
This even happens with an empty WPF project created in Visual Studio. What's even worse is that it also happens with the background and you can see stuff behind the window (other windows, desktop wallpaper, etc.) leak through when enlarging.
At first I thought that it's an ugly limitation of WPF seeing that native or WinForms applications resize just fine (if written properly). But when I look at Expression Blend the window background stays opaque (though the window content still lags behind). What do they do to prevent described problem and are there any ways to improve resizing to more approximate native/WinForm GUIs?
The reason of lags is nicely explained here
Are you running Vista without SP1 ? From what I have read, this was a common issue that is supposed have been fixed..
http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/3960d6a6-e873-455c-9ddc-1e2dd32e090b/
I'm not seeing this behavior, myself. I develop on vista x64 sp1 and/or a virtual pc running xp x32 sp3. Wpf uses directx, could it be your video card/machine? Try running your app on a diff machine and see if you have the same results.
I have the same issue with the interface lagging while resizing. I suspect that the reason for the lag is it is resizing the underlying frame buffers in direct X which is never particularly fast. I am not sure what you can do about it though.
I've been looking for information on this issue as well. I just thought it was a windows "feature" that some intrepid microsoft programmer thought would be cool. I was hoping to be able to turn it off so that window resizes would actually follow my mouse, instead of lagging and then overshooting. Grr.