I'm using VS2010 WPF / XMAL to create a very detailed order form. It has about 50 data items on it all data-bound in xaml. All is fine in development on my win7 PC. When I deploy the app, via one click or an MSI, the application take seconds to download but up to 5 mins to prepare before the login screen is shown on a windows 7 pc. But on my XP machine it's done in seconds, for exactly the same app!. I've trouble shot the order form by commenting out some of the xaml I found that there is breaking point to the amount of items it can show before I get a start up problem. For example I have 30 items without issue but once you add one more then they very slow startup times occur. It doesn't matter which area of the xaml I comment out as soon as it goes to one extra I get the slow start up time?
I'm only using grids, stack panels and textboxes with single items of data. No lists
Very strange as XP doesn't have this problem. Any ideas?
What graphics cards do you have in each machine? It may be to do with there DirectX compatibility? Changing to software rendering might give you an insight (or at least some consistency.
Try the advice from this page:
http://blogs.msdn.com/b/jgoldb/archive/2010/06/22/software-rendering-usage-in-wpf.aspx
This is the profiling tool you should use for WPF:
http://msdn.microsoft.com/en-us/library/aa969767(v=vs.110).aspx
On my windows 7 pc I changed these setting in symantec antivirus; In Auto-protect I disable the Enable File System Auto-Protect option. Also in the global settings I disabled "Insight for" and " Enable bloodhound heuristic virus detection.
After this my app loaded in a second. When I enabled the virus settings back to what it was and did a reboot my app continued load up in seconds.
I'm not sure why Symantec was inconsistent with this issue... By just adding one extra line of xaml, be it a textbox or a label I get a massive difference in behaviour. My assemblies are sign on my build server with domain certificate so I would assume they are trusted.
Related
We have a Windows Forms application used for testing our products that has had pretty much the same forms and dialogs for nearly 10 years now. AutoScaleMode in the designer is set to Font for both forms, and that hasn't changed since the original design. AutoSize is set to false and just for good measure (I guess) AutoSizeMode is set to GrowOnly. The following source lines are in Program.cs:
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Remember, this has been working flawlessly for years...
One of the recent updates to VS2017 included AutoScale support for monitors with different DPI. I have a relatively high DPI monitor, so when I made some changes to a Settings dialog (adding controls, etc) I started getting bright yellow banners cross the top of the designer surface telling me that AutoScaling was set to 125%, and would I like to change that? I tried going back and forth, and when in 100% mode (Autoscaling off) I was warned that XAML forms might not display correctly. Fine, I am working with Forms so I went back to "normal" scaling and the form looked fine.
Until I tried running the program. Now when I start the program the main form looks like this (details deleted to protect the guilty):
...but when I open the settings dialog it looks like this:
Yikes! It looks worse in practice, the relative images here don't do justice to the difference in size and scale.
I have no idea what got changed or how / why this is happening, but there's no way I can put this into production. I've tried changing the AutoScale settings, to no avail. Can somebody point me in the right direction here?
Thanks in advance!
EDIT: It seems the rescaling only happens on my machine when I run the app in Debug. Whatever is messing up the display of the forms on my machine doesn't do that on my associates' machines and isn't replicated to the executable produced by the build server.
On another note, I tried every DPI-related setting I could find, added those that weren't there due to the program's age, all to no avail. Nothing I have tried has had any effect on the program's display weirdness on my machine. Ugh.
I tried all the tricks I could find, short of disabling AutoScale completely, and nothing worked. I finally merged our develop branch in to my feature branch and inspected all 270 edits, choosing the oldest settings I could find for all size parameters, all controls. Ugh.
Along the way I stumbled across the following line in the Designer.cs file for the form:
this.AutoScaleDimensions = new System.Drawing.SizeF(6F, 13F);
This setting is NOT accessible from Visual Studio's designer, as far as I can tell, nor can I find anything about how or why it gets set. What I did find was that in the earlier version that did work as expected, the values were (8F, 17F) -- so I manually edited the line to match the older, working version. Success!
I also checked my Windows display settings, and the Custom Scaling value was at 100%, so I used the registry hack mentioned in one of the articles I found following the first link from the comment above (thanks, #Jimi) to disable auto-scaling in Visual Studio, then turned off the notification. Now I'm (finally) back in business.
Registry hack is here:
https://learn.microsoft.com/en-us/dotnet/framework/winforms/disable-dpi-awareness-visual-studio
If one uses the registry hack mentioned in the answer from DaveN59, and there is already entry for your ...\devenv.exe (mine was previously set to run as admin) then add the DPIUNAWARE string to the end of the "Data". Make sure to use a space as a separator.
Example: ^ RUNASADMIN DPIUNAWARE
I'm not sure what the ^ is for, but it was there and I just added DPIUNAWARE string. Also, if you just add this string, it will come up unscaled, but you will still see the yellow banner. To turn that off you'll need to select that option from with in Visual Studio. The instructions are in the link for the registry hack, also provided above. For conveinece here's the menu navigation path.
To disable notifications, choose Tools > Options to open the Options
dialog. Then, choose Windows Forms Designer > General, and set DPI
Scaling Notifications to False.
Forgive me if this is a technical issue rather than a software-programming one, but I am having difficulty determining the probable cause here, be it the .NET Framework or something lower level, perhaps graphics hardware. Essentially, no WPF application will run on a second monitor using my Windows 10 Alienware 13 laptop. The same application, on the same monitor, running under my Windows 8 Alienware 15, will work fine. Visual Studio 2015 is a similar case, if there might be a common factor. Any experience with this sort of issue would be appreciated
For me, the issue seems to be in the hardware acceleration in WPF applications, as disabling it made it impossible to reproduce the problem (which previously I had no trouble doing using winkey+arrows to move WPF from primary to secondary screen)
The following registry edit can be used to disable hardware acceleration inside WPF applications:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Avalon.Graphics]
"DisableHWAcceleration"=dword:00000001
Sources:
https://support.microsoft.com/en-us/kb/963021
https://msdn.microsoft.com/en-us/library/aa970912.aspx
I faced the same problem with my Windows 10 and dual monitor ( laptop screen + second monitor connected by HDMI ).
The solution in my case to fix the "black window in the second monitor" was this:
Locate your graphic-card vendor configuration interface by right clicking your desktop. In this pop-up menu you will find something like "Intel graphics" or "nVidia configuration", "AMD Control center", etc...
Find the "scaling options" and change the value. I disabled the "scaling" (OFF) and the problem was fixed, so this issue is related with the auto-scaling of the windows when you move your application between screens.
Please find these screenshots as example from my computer:
Source: https://answers.microsoft.com/en-us/windows/forum/windows_10-start/dual-monitor-different-resolutions-black-program/58ec488a-b62d-4ce8-a058-5e01e2a54d9a
Disabling hardware acceleration for the application, worked for me. This can be executed at any point and works immediately. So you can call this when the wpf app is already running
RenderOptions.ProcessRenderMode = RenderMode.SoftwareOnly;
Microsoft manual
I am using the performance analysis tools within Visual Studio to evaluate a rather large and complex WPF application I am working on. I've been able to get cold start time reduced significantly by lazy loading most of the user controls that previously I just loaded on the application start however I am still seeing the bulk of my CPU cycles spent within the assembly 'PresentationFramework.ni.dll'. This doesn't help me figure out what the root cause is because all it says is that the time is spent on a particular user control's 'InitializeComponent' (i.e. XAML parsing) or Window.Show (i.e. XAML parsing).
My question is this: how can I get more granular insights into what specific XAML elements are causing the performance issue?
I am using Visual Studio 2013 and running Windows 8.1. I used to use the old Windows 7 SDK WPF Performance Toolkit that showed a really useful rendering time display that change the color on screen when a particular UIElement was re-drawing but I can't seem to find the same tool that runs on Windows 8.
I suspect the user control has a "deep" visual tree,so it spends time initialising. I did face this myself and used a workaround to load the user controls in background as soon as the application starts.hope this helps.
Recently we installed a .net WPF application on citrix. When I go and launch it from citrix using RES powerfuse, I only get a grey screen and no controls are rendered on the screen.
The application is open and the main window can be seen but everything is grey in it. The mouse pointer also disappears behind the application.
The funny part is when the people from the operations team launch the application, it works fine. but not for regular users. This makes me suspect it could be something to do with permissions, yet we have given the access to open the program to all users, thats why the icon appears in citrix in the first place
What server are you running the app on? I recall we hit a WPF rendering bug on certain versions of Windows Server (+ XenApp) where the app would only render properly for administrators. This was a .NET bug - nothing to do with Citrix per-say. From what I remember the WPF rendering engine was trying to get access to some system resource that regular users could not access. I believe we only saw this on 2003 servers.
Just did some further digging, I think this is the issue:
http://support.microsoft.com/kb/955692
For quick n temporary resolution:
Check your local machine resolution and Citrix desktop/application resolution.
Equalise the both it will work.
Ex: 1024/762 is the right resolution.
For test: Do maximise n minimize the screen you will see the change.
I'm having problems with the rendering of a WPF app over a remote desktop connection.
The applications chrome is rendering, but none of the content is coming through, as if the window is not drawing. Instead the previous content of the screen is showing in it's place.
This has been a problem with the application running on both Vista & Win 7, with remote control being taken from XP and Win7.
The problem is not application specific, if I create a new WPF app, with just a textblock on the window, it will also not run. (Neather will the windows preview in VS2008 display.)
Is there some trick to getting WPF running under RDP?
I read on Kevin Dente's blog (from a twitter post) that he was having trouble with WPF apps in virtual machines. While not the same as Remote Desktop, it's possible the problem could be the same. Kevin was able to fix his problem by disabling hardware accelleration by creating a DWORD registry value at
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Avalon.Graphics\DisableHWAcceleration
and then setting it to 1.
His original blog post is here: http://weblogs.asp.net/kdente/archive/2009/10/19/visual-studio-2010-beta-2-editor-performance-fix-running-on-a-virtual-machine.aspx
That may not be your exact solution, but maybe it points you in the right direction.
WPF should render over RDP; it's smart enough to know when it can render in hardware, and when it can't it reverts to its own GDI+ based software rendering. I would make sure you're running .NET Framework 3.5 SP1 on the remote machine, since there were changes to remoting that might pose issues. (See link below.)
I've been developing a WPF app for the past 6 months and it works just fine over RDP. (From Vista and Win7 to XP, Vista and Server 2003.) One important caveat, however, is that it renders using the Classic theme. So if you're using controls that don't have a classic theme, they won't render. If you're just dropping a TextBox on a Window, then obviously that's not your problem.
Check out this question for some links that may be helpful: Are there problems with rendering WPF over Remote Desktop under Windows XP?
I just had this problem with the ribbonwindow not displaying correctly when testing for the first time via RDP - the transparent background was white, the close minimize/maximize buttons were missing, the rounded corners on the bottom of the window were square, and the top row of ribbon buttons were almost impossible to select.
Turns out there was a simple fix for me. Right-click the RDP connection icon (I have it saved on my desktop), select "Edit", then the "experience" tab, and change "detect connection quality automatically" to "LAN (10 Mbps or higher)".
This fixed it for me.
Ade
Did you also try Win7 latest RDP - Win7 connection? The thing is WPF doesn't use GDI to draw elements.
VNC clients (like UltraVNC) probably will do the trick for you as they using much simplier algorithms more like of sending bitmaps.
I have the same problem than the asker. The standard, out-of-the-box Checkbox is not rendering correctly. I can only see if it is checked when hoovering the checkbox. Otherwhise, no difference between checked and unchecked. Important note : It occurs when setting the foreground to white (see here : https://social.msdn.microsoft.com/Forums/vstudio/en-US/1c03db49-7e53-4cbb-9dd1-b328017c4453/wpf-checkbox-and-radiobutton-check-mark-not-showing-under-xp-windows-classic-theme-and-remote?forum=wpf)
Our application used to have this problem with a custom progress bar.
We fixed this by setting the background color of the Border control to White. This leads me to think there is an issue with transparent backgrounds
There is no special trick needed to get WPF content to show across remote desktop. Our WPF-based app renders just fine over RDP (tried from numerous machines) with no problems. We're even using animations, gradients, WriteableBitmap, etc. w/ no problems.