We have an old (Win32) and new (WPF) version of our blotter software, which the traders are currently running side by side. However, running the WPF application often severly slows down the redraw rate of the Win32 application.
Without the WPF application running (or minimized), draw rate is fluid and fast in the Win32 application. With the WPF application open alongside it, the Win32 appl's UI draw rate slows down noticeably. Running the WPF application seems to trigger use of some resources which are taken away from the Win32 app (both graphics-heavy) - causing the slow down it seems.
CPU and Memory are not anywhere near being saturated, so it doesn't seem to be related to those. Lowering resolution and/or reducing the number of monitors to display on (therefore decreasing video card memory usage and bandwidth load) makes no noticeable difference, therefore it doesn't seem to be a graphics hardware performance issue either.
One hypothesis that may explain the cause is as follows:
Under the hood, we know that both the WPF and Win32 applications output graphics information to a windows "message pump" which is basically a queue of instructions of what to draw to the screen. It seems as if when the WPF application is not running, the Win32 has full unfettered access to this and screen updates are fluid. Running the WPF application alongside it puts additional messages on this queue, so Win32 application has to compete harder for access to it (in order to do each screen element update), therefore "clogging the pump" giving the effect we see.
If the above is the case, can anyone recommend approaches to manage/control the window message pump in order to prevent this happening?
The flicker is the type you typically get when resources run low, where you can see individual elements (forms, labels) flicker and gradually draw on to the screen.
If anyone has any suggestions/ideas, let us know.
Each process will have its own message pump - this is not shared.
If you are not seeing high CPU utilization, then WPF is using hardware rendering, so it could possibly be GPU saturation. Can you get information on GPU utilization?
The following post details methods of getting GPU utilization:
Programmatically fetch GPU utilization
Okay, I think we've found the cause, and fix. In a nutshell, hardware and software accelerated windows don't play nice. Using software-rendering across the board fixes glitches that were previously there when running hardware-accelerated windows. Since our legacy Win32 app will be decommissioned soon, this is a workable comprimise - we can simply switch hardware acceleration back on when we drop the legacy application.
Notes below:
It seems like this issue is being caused by running a traditional software-accelerated 2D application (X) and 3D hardware-accelerated WPF one (Y) at the same time, and is a graphics driver issue.
Forcing Y to run in WPF software-acceleration mode as well causes little degradation in scrolling performance (as the bottleneck is still the grid's internal layout code).
However, what it does do, is get rid of the slow drawing issue in X, because Y is now running as a software-accelerated 2D application, like all other Windows applications on trader's machines. This explains why no applications other than Y caused slowdown - it seems as if software and hardware-accelerated graphics applications don't play nice when run at the same time.
This makes sense - when I play a hardware-accelerated game, for instance, I've seen similar (where the desktop redraws very slowly when switching to/from the game between hardware/software acceleration modes).
Thankfully we can turn off hardware-rendering without much impact in performance. Once X is decommissioned we can switch hardware-acceleration back on for the minor benefits it provides in Y (support for smoother animations and heavier use of fill gradients without slowing down etc).
Related
So I have a WPF application which contains lots of real time effects - drawing directly to bitmaps, shader effects, etc. - and it all works great.
However, GPU usage is a bit higher than I would like, It hovers around 20%. I during the process of optimising, I tried attaching the Visual Studio profiler. When this is attached, and GPU Usage is selected as one of the profiling tools, when my WPF application runs....... the same app, with the same content....... GPU usage hovers around 5%!!!
After a heck of a lot of messing around, it does indeed seem that yes, when the profiler is attached (specifically GPU Usage, doesn't happen e.g. with just CPU usage selected) then yes the GPU usage plummets.
Please note the following (and I reference 5% and 20% as being if the profiler is attached or not)
I monitored GPU usage in task manager, and cross checked in Windows Performance Monitor/perfmon with the gpu are showing the same thing, I do not believe it is being misreported
You can look at system power monitoring and physically see more power being used under higher load level
If pushed my applications content, you can visually see in certain cases that at 5%, things run a bit smoother than at 20% (less frame drops), though in general...
Frame rate at both 20% and 5% usage is same 60fps
Happens if run directly in visual studio as debug, release, optimisation on or not, whatever
Happens if published and run stand alone
You can attach visual studio at run time with it's profiler (GPU tool) - starting and stopping the profiler literally toggles between 5% and 20% usage when you do it - no restarting my App or anything
Profiling everything in detail using visual studio, jetbrains dotTrace etc. does not identify any noticeable differences in the running app during 5% and 20% usage. E.g. jetbrains output showing call trees, time spent processing, call rates, etc. - 5% and 20% produce the same outputs.
Good old WPF Performance Suite/wpfperf shows no difference between 20% and 5% usage of number of calls being made etc. (though the visual profiler doesn't seem to work with latest .net core unfortunately)
GPU profiling is not showing any difference in VS
Nvidia CUDA toolkit - well it didn't want to work trying to profile this. Nor did RenderDoc - so did look at those.
I can scale the usage of gfx used in my app up and down, to vary the 20%/5%, but there is always a difference between profiler attached or not
Playing with the windows timer, just in case - Windows low level system timer resolution running at a consistant 1ms for both 20% and 5% - and confirmed no other known power saving settings are being changed. This was confirmed both at run time, and variants where I manually set things in code.
My app is a .net core 3.1 app. GFX is an nvidia GTX 2060s.
Of note, I have seen similar before in a separate WPF app (lots of 3D inside it, running .net 4.x framework) - where running the gpu profiler as above would make the 3D rendering run more smoothly. Tested on different pc's with different GFX hardware. It is also the same across different versions of GFX drivers.
Absolutely stumped what might be causing this.... I wouldn't mind if it was the other way around and was 4 times faster when no profiler was attached!
I am aware that when profiling, various things might get set in the background. I would have no clue at all what these might be.
Does anyone have any ideas at all?
Many thanks
Martin
Extra:
I found something similar, which is when the debugger is not attached in visual studio then performance is better - but my case here doesn't require any debugger, and appears to be GPU profiler specific, so don't believe it is anything like that. Why does my program run way faster when I enable profiling?
Example screenshot of performance on system demonstrating this...
High usage = no profiler attached. When everything drops, the profiler is attached and running (from around 15-38 seconds). Big red arrows = my task. Note there is other activity going on, including visual studio starting up the profiler, detatching it, etc.
Example project (source + built) you can see this happening...
https://1drv.ms/u/s!As6cQRoZ5gU5x8FzXdwcYS1qEFqjdg?e=98o64j
...note this is a new WPF project, created 15 minutes ago independently of my original project, with a test 3d object loaded into it - and also shows a performance difference - almost 50% less on my pc when visual studio gpu profiler attached
I have a very weird bug that I just can't understand.
I am currently using the WPFMediaKit library in one of my programs.
When using the library in a near empty new "demo" wpf solution, the image from the USB Camera source is rendered perfectly to the MediaCaptureElement class.
However, using a more complex solution, the same library (without changes), the frame gets rendered black. I can see there is connection to the camera and everything goes well, DirectShow graph is built normally and everything just looks fine, besides the black frames. I can even open the camera properties and see it pushing out frames as usual.
Also, this only happens on Dell E6540 (With an AMD and Intel HD gpu) if it's Windows 7. Windows 8/10 work fine. Have tried a lot of drivers nothing seems to change the output.
I have no clue what to do or what to try.
After many hours and just after deciding to post this question, I found the answer.
The more complex solution, under the AMD Settings application was set to use "High Performance" mode, this mode was automatically enabled on Windows 7 for some reason. Disabling that and setting it to "none" or "lower power" fixed the issue.
Doesn't change the fact that there is an issue with laptops with dedicated AMD GPUs, probably something to do with DirectX/Direct3D which is used to render the frames.
I grabbed this multi window test code, changed it to use D3DXCreateTeapot instead of D3DXLoadMeshFromX (I couldn't find a teapot.x file), moved the EndScene call below the DrawText call and set NUM_WINDOWS to 1. With those minor changes, the test works and creates two windows, each with its teapot.
I built the test and deployed it in a machine which has an Intel HD Graphics onboard GPU with two heads, each attached to a monitor. Then I moved one window to each monitor, and enlarged both windows to take up about 80% of each monitor space.
With this setup, which is quite close to what my app needs, the window in the secondary monitor always goes too slow. If I swap the windows, it's the same: the one in the secondary monitor starts crawling, and slows down the whole system.
I googled around and some sources (albeit dated) state that only the primary monitor can use hardware acceleration when not in fullscreen mode. I cannot use fullscreen because direct3d9 rendering in my app is done inside a user control embedded in a Winforms GUI.
Is it really impossible to get hardware acceleration for both monitors in windowed mode? The legacy version of our application uses MFC + DirectDraw and manages to perform fast enough, but those are obsolete technologies and we'd abhor going back there.
You have 3 options:
Try many combinations, like: D3DPRESENT_INTERVAL_IMMEDIATE +
(D3DSWAPEFFECT_FLIP or D3DSWAPEFFECT_COPY) +
D3DCREATE_ADAPTERGROUP_DEVICE. Maybe some will offer better
performance.
Render to a surface, convert to a bitmap, and use it like any other bitmap in your form. Something like this
D3DXSaveSurfaceToFileInMemory.
Change your code to DirectX11. You have more options for GDI interaction there. Better rendering behavior. Maybe better drivers.
Some years ago, I made some multiple window code, also multiple device, using DirectX10/11. I can't tell about DirectX9 having this issue, seems absurd to me, but could be your Windows version, or Intel driver.
Here is the situation. The company I work for builds this piece of software in c that can make a Windows computer act a bit like a TV. Essentially, our piece of software is meant to be played full screen and content is displayed from the internet without the user having to ever touch the computer again.
The problem is that once in a while, the system brings up pop-ups like "Your Windows system is ready for an upgrade." or "Please renew your Norton subscription" etc. which the user has to periodically and manually remove.
Is there a way to display content full screen without being bothered by those warnings?
Yah, whether or not the development community agrees, Microsoft has several standards for when and why it might be acceptable to have exclusive use of the monitor.
The most official strategy is to use DirectX in exclusive mode. This is what games do, what windows media player does in full screen video with hardware acceleration enabled, etc... If your application is multimedia intensive (as suggested by TV like functionality), you should probably be using DirectX too. Besides giving you the exclusive display access it will also increase your applications performance while lowering the CPU load (as it will overload graphics work to the video card when possible).
If DirectX is not an option, there are a great number of hacks available that seem to all behave differently between various generations of windows operating systems. So you might have to be prepared to implement several techniques to cover each OS you plan to support.
One technique is to set your application as the currently running screensaver. A screensaver if really just an EXE renamed to SCR with certain command line switches it should support. But you can write your own application to be such a screensaver and a little launcher stub that sets it as the screensaver and launches it. Upon exit the application should return the original screensaver settings (perhaps the launcher waits for the process to exit so that it returns the settings in both graceful exits and any unplanned process terminations ie: app crash). I'm not sure if this behavior is consistent across platforms though, you'll have to test it.
Preventing other applications from creating window handles is truly a hack in my opinion and pretty bad one that I wouldn't appreciate as a customer of such software.
A constant BringWindowToTop() call to keep you in front is better (it doesn't break other software) but still a little hack-ish.
Catch window creation messages with a global hook. This way you can close or hide unwanted windows before they become visible.
EDIT: If you definitely want to avoid hooks, then you can call a function periodically, which puts your window to the top of the z-stack.
You could disable system updates http://support.microsoft.com/kb/901037 and remove the norton malware.
You could also connect a second screen so that the bubbles appear in the the first monitor.
Or you rewrite it for linux or windows ce.
One final option is to install software that reconfigures your os into a kiosk http://shop.inteset.com/Products/9-securelockdown.aspx
If you don't need keyboard or mouse input, how about running your application as a screensaver?
A lot of thoses messages are trigged/managed by Windows Explorer.
Just replace it with your dummy c#/winform.
By changing the registry value
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"Shell"="Explorer.exe"
You can specify virtually any exe as an alternative to explorer.exe
That's the way all windows based (embedded) system (ATM & co) do.
There's still few adjustment (disable services you dont need / dr watson & others), and of course, you'll want to keep a "restart explorer.exe" backdoor.
But that's a good start
i have a WPF application that sits on top of all other windows. 99% of the time it works perfectly however if i dial into my computer from another location using remote desktop and then close the connection and go back to the original computer, my application is not visible. checking the running processes i can see that it is still running however its not visible at all. I assume it has something to do with the remoting but i was wondering if there is some code i can run say every 20 seconds that sits on its own thread that checks whether it is visible and if not will execute some code whether by pInvoke or .NET to become visible again. Any ideas?
Make sure to upgrade to .NET 3.5sp1. There were some changes with remoting which lead to WPF applications being sent as bitmaps in remote desktop in all situations.
In earlier versions of the framework, there were problems with WPF applications causing very odd behavior when combined with remote desktop.
Another idea - make sure you're using the latest and greatest versions of your graphics drivers from your graphics card vendor. WPF makes heavy use of DirectX, and this could potentially be a driver bug preventing the context from resetting appropriately.