We have a C# WPF application written in .Net 4.0, which some relatively simple data binding and grid functionality.
The styling invovles a few 'tweaks', including some hover colours and so on.
On 3 machines, out of a deployment covering 20, we are experiencing some very strange performance problems with the UI.
Effectively, after a reboot the application performs well, but after a certain (un-determined) amount of time, the UI becomes incredibly sluggish. For example, hovering the mouse over a button, and there will be a delay of up to a couple of seconds before the hover colour styling gets applied / rendered.
The machines have almost identical specifications. The graphics drivers have been updated, and the starndard setup is two NVidia Quadro 290 cards. Additoinally, we made a 'test' application containing ONLY some test UI components (including the Fluent Ribbon) and no code behind. The problem still occurs.
I have run the Windows Performance Suite to 'deep dive' the runtime WPF, and, very strangely, the UI returns to normal responsiveness if the option 'Disable Dirty Region Support' is ticked. My understanding is that, if anything, this should decrease performance further!!!
I'm at a loss of anything else to try here. A DotTrace performance analysis suggests most of the application time is spent in the PresentationFramework.dll.
[EDIT] All machines are Windows XP SP3.
[EDIT] It is possible that this occurs on all the machines and that the application is not usually allowed to run for long enough to present the problem. We are testing this now.
[EDIT] I should also point out that we are experimenting with the hotfix detailed here. It has been installed on a single machine for the moment, and I will update accordingly.
[EDIT - 24 hours later] So two machines have now been running the same code overnight. On my machine (which has never demonstrated the problem), after initial log in the application was very sluggish, but after less than a minute returned to normal. (I put that down to the machine clearly pulling things off the HDD). On the other machine (which usually demonstrates the problem), the applicaiton improved after a few seconds, but is still now sluggish in comparison to mine.
[EDIT - 48 hours later] On the test machine, the test application is now completely unresponsive (locked) after running for 48 hours. On the same machine, a lightweight 'shell' WPF application (containing a tab control, some buttons and a few panels and grids) is still running and perfectly responsive. So something in these more complex controls is causing this issue... which does indeed point back to (potentially) triggers and delegates that might be the root cause. I'll look to profile the application / controls again. In the mean time does anyone have any advice about how to ensure that the application 'cleans up' after itself at regular intervals? Because we are looking at third party controls here, so my options for editing them are limited!
Would appreciate any tips that can be provided!
try to render wpf in software mode.
in Loaded event:
HwndSource hwndSource = PresentationSource.FromVisual(this) as HwndSource;
HwndTarget hwndTarget = hwndSource.CompositionTarget;
hwndTarget.RenderMode = RenderMode.SoftwareOnly;
Something to consider when comparing performance between developer and user machines is the time it takes to load the WPF assemblies.
On a dev machine you might already have visual studio running or have previously run other WPF apps and the assemblies should all have been loaded by the time you run your app.
On a user machine, perhaps freshly rebooted, the assemblies will be loaded when the app is started, making startup significantly slower. Depending on how the app is setup there might be additional assemblies loading when various features / pages are used for the first time.
I've found the EQUATEC profiler to be useful in debugging these performance issues. Changing the profiling to "Full usual info" in the app options before building your project will profile down to the binding level.
Related
After updating windows to version 1803 none of the WPF applications on a laptop (Intel hd 500 GPU) work properly anymore (start with a blank window or don't show the GUI at all). I've made a simple test app that only shows one button and it results in an empty window. If I turn off the hardware rendering (according to Software rendering mode - WPF), the application works as expected.
I've tried several versions of the GPU driver including the generic MS one, latest one, latest one recommended by the laptop manufacturer, older ones but all with the same result. The recovery point to the previous version is not available anymore.
The laptop is barely running existing applications so setting the registry not to use the hardware rendering for all the .net applications is not an option due to performance degradation.
Has anyone experienced anything similar, are any other solutions to solving this?
Thanks,
Tomislav
The issue happens because I'm using the laptop with the lid down (I connect remotely to it). This seems to put the GPU to sleep/power down state which messes up the applications that use GPU acceleration. Interestingly desktop and some applications run normally.
Adding a fake display solved the issue (https://forums.lenovo.com/t5/ThinkPad-X-Series-Laptops/Working-with-closed-lid/td-p/1623610, https://superuser.com/questions/1271344/fake-montitor-for-teamviewer-on-laptop-with-closed-lid).
I have also had this issue and have found that if you uninstall and delete the Intel Display Adapter, then let Windows automatically find the default, this issue is resolved.
I have encountered a very weird situation:
I have developped a rich WPF client in C# for a client of mine. It performs well on all our developer machines but poor on my client's computers (in some respect - see below).
Well the weird thing is:
If have set up a virtual machine for testing. When I start my app from the explorer or the console the app performs poorly. But when I start the same app within visual studio 2017 it performs well! There is no noticable difference between debug and release. Also "start without debugger" performs well.
I not see any bottleneck during tests: not much CPU usage, not much DISK IO, not much network IO, not too much memory consumption. Noticable is when my application is lagging that the state in the windows 10 task manager changes from "beeing executed" to "inactive".
I am using WPF, C#, Oracle Database (via .NET Native). There are several mask my client has problems with but I am currently debugging one dialog which has 7 lines (read from the database) times 26 textboxes with databinding. The problem occurs when I change the data displayed. It seems to be lagging when the the Datacontext of the line (panel) is changed to the new loaded object.
I am grateful for any hints of what might happen oder how I investigate that any further.
Edits:
- described the actual problem in more details
I have an issue with my C# application. It's about controls on borderless form. I've created a application that works like a logging system (shows in center of the screen, has 2 textboxes, 2 comboboxes, 2 pictureboxes, form StartPosition is CenterScreen). The application works fine on almost every system, 30 - 40 people are using it, but 3 of them has a problem, that makes the app useless.
The controls are totally moved and seems little bigger than they
should be, 2 of these controls are moved even outside the form - which
makes them inaccessible.
I've tried to set the compability mode and change the screen resolution. No luck.
All of these problematic machines has Windows 7 and default .NET 3.5.1, one has 4.0. The application was targeted for .NET 3.0 (I wanted to keep it free from dependencies on machines with Vista and newer).
I'm looking for a advice from those, who had experience with this kind of problem. I would like to keep the form borderless, its essential for its design, and keep the target framework if possible. What can i do to keep this in solid ?
I'm guessing you have problems with DPI. Try increasing it on your dev machine and I bet you will see same effect. I hadn't worked with winforms for a long time, but I think you can use this article to help you out.
After spending 14 hours on this I think its time to share my woes and see if anyone has experienced this issue before.
Ill describe the issue and tests I have done to rule out certain things.
Ok so I have a WPF application which loads in data from an SQL database.
I am using DevExpress Components for datagrids, ribbons etc.. and FluentNhibernate to provide a session for database operations. I am also using log4net to log events to a textfile.
Using the application on my laptop with SQL Express 2008 works fine.. the application starts up, retrieves 1000 records and I can tab through the controls on the ribbon.
Now, I decided to demo the application to a third party and used remote login/sharing software online to share my desktop with the other person so as I could load the application on my laptop and they could view me using the application.
Now, the application takes approx 45 seconds to load... 30 seconds with a blank database where as, when im not sharing out my screen using the online software the application loads in about 7-10 seconds. As well as that, even using the controls in the application during the demo were very sticky, slow and unresponsive.
During the sharing session though however I was able to use other applications without any problems.. everything else worked fine.
But I cannot understand how my application works ok under normal conditions , even browsing the net at the same time etc... BUT totally fails to perform correctly when I am sharing a session with another user... the CPU usage shot up to 100% too at times when the application was trying to start up...
Please see below a list of 3rd party dlls I am using as references in my project.
DevExpress dlls
FluidKit
PixelLab.WPF
PixelLab.Common
Galasoft WPF Kit
FluentNHibernate
NHibernate
Nhibernate.ByteCode.Castle
Skype4ComLib
TXTEXTControl
log4net
LinqKit
All of these DLLs are in the output folder with the application dlls created from the class assemblys in the project. So when installed via an installer on a machine the dlls will be in the same application folder as the application file itself.
Many thanks
I saw something similar about a year ago with logmein. The performance is not the app its the graphics processing . WPF renders graphically in a completely different way then GDI winforms see around 2.3 and down msdn article. Many remote desktop application have trouble rendering this correctly particularly if you don't use the plug ins (say logmein). You didn't say what you were using but I would suggest trying a few different RDP options as there are many out there, and making sure your on the newest versions.
Yes, as bumle-bee-tuna points out, WPF will default to software rendering over Remote Desktop. Another way may be to screen share using Skype or similar. This means you'll be rendering the app locally but transmitting an image to the remote user. the app should work at full speed and the only lag the viewer will see will be introduced by the Skype network. I've used this technique many times to deliver presentations remotely and works well!
I've written a WPF application (in Visual C# 2010 Express) that has 2 windows. The 1st has a various buttons, the other displays video using the MediaElement control. When a button is pressed, a video associated with it is played or stopped if it's already playing.
On my development machine (Windows 7, good graphics card, lots of memory etc), this runs fine. The only problem I've encountered is that when attached to the debugger it is very unstable but when run normally these issues go away.
Unfortunately when run on a much less powerful XP machine the videos run at 1-2fps. This is despite the fact that the videos run fine in Windows Media Player.
There seem to quite a lot of reports of poor performance for the MediaElement control (not to mention inconsistencies in what it can play) so I decided to look at some alternatives.
I tried a free library call WPF MediaKit (http://wpfmediakit.codeplex.com) that I thought might have some effect, however while I've got it to work on an XP machine, it resolutely refuses to display videos on my development machine despite using exactly the same code. I'm still hoping I can this to work but I'm not confident it will help given it's still using the MediaElement control behind the scenes.
I then tried using wmp.dll COM control (Windows forms rather than WPF) and even with the simplest app (new Windows Form project, WMP control added to form, and 1 line of code to set the URL on load) I get odd behaviour. With the debugger attached, it works across multiple monitors, but sometimes when it starts playing, it just repeatedly stutters over the 1st few frames and the only way to break it out of this seems to be to move it to the other monitor. If I'm not using the debugger, I don't seem to get the stutter issue but the video is only displayed on the main monitor, as soon as I move the window to the secondary monitor, it goes black.
So my question is has anyone experienced anything like the above and/or have a decent solution to it? It would be especially nice to find something that works consistently with and without the debugger attached!
Have you tried this library?
http://directshownet.sourceforge.net/about.html
There's also this .NET interface to VideoLAN media player, but that introduces a dependency to VLC:
http://wiki.videolan.org/.Net_Interface_to_VLC
WPF MediaKit does not use MediaElement behind the scenes, but instead uses the D3DImage interop class to provide high performance video to WPF.
WPF in XP has always been a hit-or-miss in terms of performance. You might want to take a look at the rendering tier to ensure WPF is fully hardware accelerating. Also make sure you have the newest video drivers available and that the GPU is capable.
-Jer