The title pretty much describes it. If I resize my WPF app so that it stretches over two monitors in a dual monitor setup, and resize it back, there will be a ghost window in the second monitor that does nothing, but is still moved when I move the original window in the first screen.
Has anyone had issues like this? I think its a refresh bug on some OSs (I use WINXP 32 bit), but would like to confirm with the community.
This is because AllowsTransparency is set to true. Haven't figured a workaround yet but as soon as I set it to false I didn't see the ghost.
Yes, we get this a lot. Usualy it is related to old hardware (eg. integrated graphics card), but it happens on new as well (eg. quadro NVS 295 with the latest drivers). Sometimes the amount of ghosting depends on the speed the windows is dragged with.
Then again, we can't reproduce it on quadro 450 or 290 so it seems it's a driver issue.
There are 2 ways to solve it - set AllowTransparency to false or disable HW acceleration.
This being said, this is one of the smaller problems we had with WPF in multi-monitor environments...
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 have my main window at something like 6000 x 6000 px. In that window, I can have a lot of controls (more than 5000) and we can zoom/pan where we want.
I added 10 "television screens" controls in my application, and each of them have a refresh rate of 100ms.
When I start this, everything crash...
10 objects with a refresh rate of 100ms each is too much, WPF cannot draw them at the time. I conclude that WPF is very slow to draw what I have....
Everything is drawn in vector, but I tried to add .CacheMode on them and it doesn't work either..
What can I do?
P.S. My PC is 8 core, 8 GB Ram, 256 Mb video card (nvidia quadro nvs 295) on win7 64bits
WPF uses software rendering in case you exceed maximum supported resolution of you graphics adapter. Moreover, 5k controls! Incredible. WPF is not a silver bullet for everything you imagine. You need to redesign your app or change technology you're using.
Work on reducing the number of controls in your application. 5K is quite a bit, and I think there is probably a way to reduce that number.
For example, use TextBlocks instead of Labels as TextBlocks render as 1 control while Labels render as 3 in 4.0 (I think its more than 3 in older versions)
Also, check and see if you can use UI Virtualization with some of your controls. Something like a ListBox of 100 items can be virtualized to only render 10 of them at a time.
Take a look at ZoomableCanvas - 1 million items. This is the best example out there of what WPF can do when using every optimisation in the book. I suggest you take that example and run it at the maximum resolution on your monitors. If that fails to perform well, then WPF cannot do this.
I was unaware that WPF default to software rendering if the resolution exceeds that of the video card. A good caveat to know about!
Regarding high performance graphical APIs I second Keiren and say use DirectX (SlimDX provides a managed wrapper) instead.
I'm trying to use an existing internal WPF application (I do have access to the source), but it was developed on XP and I'm using Windows7 64-bit.
When I click (for instance) the File menu, 90% of the time I see no drop-down menu at all. The menu still exists - I can use the arrow keys to navigate up and down and choose an option if I happen to know the order of the options, but nothing renders at all.
The other 10% of the time, the menu or some portion of it DOES render, but as I move the cursor up and down I get graphical corruption or disappearing options until I end up back at the "no menu is visible at all" state.
This is also true of combo boxes within the application - they show no data when I drop them down, but I can arrow down and choose an entry.
Microsoft has some advice about WPF rendering issues here but none of these steps has helped with my issue.
Edit: a coworker running Windows 7 sees the menus just fine... he has a different video card, so I'm curious whether this is video-card specific.
This also sounds similar to an issue we had seen in XP, where comboboxes (or menus) would not display properly some of the time. There is a Microsoft hotfix (for at least one flavor of it) here, but unfortunately it is for XP and WS2003. I'm not sure if this could point you in the right direction.
The link to this hotfix was found in this MSDN thread. I am not the author of this particular link, although I do remember raising this issue some time (and a different job) ago.
It turns out that in this specific case, the issue is only present on boxes that have a GeForce 6800 video card. Updating drivers has no effect, but switching to a 7800 makes the issue go away.
I have no idea why this is the case, and I haven't found any information online about 6800-specific graphical issues in Win7 64, but our testing and experimentation shows this is the factor that causes it.
Crazy.
See this question. It's probably a problem with a DropShadowEffect, removing the Effect should fix the problem.
I second that the issue is related to NVidia Windows 7 x64 drivers. Recently I had to replace my video card. Now I have Quadro FX 3400 with the latest drivers and am seeing similar behavior. WPF ComboBoxes don't render dropdown portions. I can only switch values with keyboard after a few attempts. It could be Direct2D-related issue. I also had to turn that off for Firefox to start working again.
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.
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.