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.
Related
Im beginning in my journey of learning WPF. After a few days of coding I see that whenever I resize any WPF form I get a black border on the bottom and right while resizing, like an artifact, as if the screen is too slow. When working with winforms I never noticed this.
Like so :
Is this a known problem? any simple workaround?
EDIT 1:
Seems its related to the graphics driver, I only work on laptops with weakish gfx cards, so does anyone else have this issue? (Im also using Win7 SP1)
It's a known problem, and it's unlikely that it will be fixed. There is a work-around that reduces the impact of this problem if your background is sufficiently uniform: https://stackoverflow.com/a/14309002/33080
My understanding of the underlying cause is that WPF controls lag behind on resizes: WPF draws them in the "wrong" location briefly. See the linked question for a demonstration.
If you resize a window it has to redraw. This takes some time and also it occurs after the window manager already resized your window and shows it; in that case you'll get a black border in WPF and one with the normal window background (grey, usually) in Windows Forms.
Usually all you can hope for there is that the computer is fast enough with the redraw to not show it.
I'm using System.Drawing.Graphics.CopyFromScreen to grab a partial screenshot of the desktop. I've noticed some curious behaviour. On some machines, when the application (WPF) window has AllowsTransparency="True", calling CopyFromScreen will capture whats 'under' the window. But on other machines, it captures the calling window too.
I've tried it on a number of machines, and operating systems, and haven't found a pattern. On XP and Windows 7 laptops it captures under the transparent window. On one windows 7 desktop we have, it captures the window itself. Aero, or other Windows 7 display features seem make no difference.
Could it be a graphics card issue? Is there any way to get consistent behaviour across all machines, or to predict or detect when this issue will occur?
EDIT Thanks to the link provided by Hans Passant below, and some further testing, I now understand that this issue connected to window transparency only. On some machines, CopyFromScreen captures all windows, on other machines it only captures non-transparent windows.
Not so sure about the sometimes-not behavior. Layered windows have been behaving oddish since Aero. What is definite is that Graphics.CopyFromScreen() will not capture layered windows by default unless you use the overload that specifies the CopyPixelOperation. The required option is CaptureBlt, described as:
Windows that are layered on top of your window are included in the resulting image. By default, the image contains only your window.
Which is not accurate, "your window" won't be captured if it is a layered window. What's worse is that the method has a bug. You don't only need CaptureBlt, you also need SourceCopy. And the argument validation code doesn't permit that combination, you'll get an InvalidEnumArgumentException when you try to use it.
Well, GDI+ is a bag 'o bugs. You'll find the ugly pinvoke code you'll need to work around this in this answer.
I have a problem with Visual Studio 2010. It happens when I scroll down/up, for example, in properties window. Its content becomes blurry for milliseconds.
It also happens in my own WPF applications when I use a “ScrollViewer”.
Does anybody know how to solve it?
In your own WPF applications it is possible to constrain scroll offsets to device pixels by using a custom IScrollInfo implementation. This is easy enough to do. Note that you will have to get the actual screen DPI to do the calculation.
In Visual Studio there is no "reasonable" way to fix it. Obviously you could hack up the VS.NET executables to include your own IScrollInfo implementation, but I wouldn't recommend it!!
Just about the only way to avoid the problem is to avoid WPF entirely. As nice as it is in some ways, it still1 doesn't get text entirely correct. And yes, WPF is the source of the problem in Visual Studio -- as of VS 2010 they switched parts of it to use WPF.
1"still", in this case referring to the fact that it used to be even worse. As of .NET 4.0 they've fixed some of the most egregious problems, but (as you've seen) it's still not really right.
I had the same problem. There is actually a way to fix this while scrolling.
Just add those 3 attributes to your content control:
SnapsToDevicePixels="True" UseLayoutRounding="True" TextOptions.TextFormattingMode="Display"
Just note that the text might not look as smooth as it should while scrolling (instantly goes away once you stop scrolling though)
I am developing a Windows Forms application using VS2008 on Windows Vista. I tried to run my application on Windows XP the other day, and everything on GUI was messed up. I realized that I developed the application using 120 Dpi setting on Windows Vista and my XP was set to 96 dpi.
My application has several UserControls and all of them shrinks even in the Visual Studio itself if I change my DPI to 96. I am sure a lot of people are using Visual Studio in high DPIs these days. So how can make sure that my GUI does not get messed up both in Visual Studio and runtime?
EDIT: I have read couple articles on this issue and I learned that I should be setting AutoScaleMode to None. However, this still does not prevent my labels to adapt new DPI settings enforced by the operating system. I need a way to prevent my labels to grow/shrink because other GUI elements have fix sizes.
It has been a while since I worked on this issue, but try setting AutoSize = False. In addition, UseCompatibleTextRendering = True might help.
This is a rather old question, but I want to share my solution/opinion. I ran into a similar problem recently. Actually, I want Visual Studio to keep my WinForms as they are, but them to scale at runtime. I found no consistent summary on how to correctly do that. After some reading and experimenting I came to this solution:
Keep the Form’s AutoScaleMode = Font.
Set in your Forms Designer: Font = MS Sans; 11px
In the Forms Ctor, after InitializeComponent, set: Font = SystemFonts.DefaultFont
Enable DPI-Awareness, either through a manifest or by API function SetProcessDPIAwareness
Since AutoScaleMode remains active, all DPI-changing magic works, even per-monitor DPI awareness. What remains, is designing Forms in a way scaling works nicely.
I wrote the details on my Blog: http://www.sgrottel.de/?p=1581&lang=en
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.