Not sure what is going on here, if it's just my computer, or a VS bug. It is annoying.
When scrolling, text in VS sometimes gets really messed up. it also happens to other window elements on occasion.
I've noticed something similar in Dreamweaver CS4 & CS5, so I don't know if it's my computer or something with WPF.
Any way to fix this problem?
Windows 7 Pro
This is most likely a general WPF issue, and could be related to your graphics drivers.
I would recommend looking for updated graphics drivers for your graphics card. If this doesn't work, try reducing the amount of hardware acceleration, as this tends to clean up many WPF rendering issues.
I would suspect this is a WPF issue that may be resolved by updating your graphics drivers if your card can handle it as Reed Copsey suggested.
If you don't have any luck with that, you can try turning off some of the hardware-accelerated rendering by going to the Tools menu, selecting Options then disabling the Automatically adjust visual experience based on client performance option and the following two options under the Environment > General section.
MSDN put up an article not too long ago that can help troubleshoot the problem.
http://msdn.microsoft.com/en-us/vstudio/ff716700
The first two things I would try would be to update your video drivers. Then maybe turn down hardware acceleration.
This KB article touches upon how to do it about half way down the resolution section.
http://support.microsoft.com/kb/263039
I have similar problems with my VS2010. It isn't a graphic driver issue but an issue with WPF/VS2010. I was hoping the SP1 would solve this problem, but it didn't.
Related
This is essentially a re-state of a question I asked yesterday because the one answer I got didn't appear to understand my question so I must have been unclear. My bad.
Because WPF relies on DirectX it's very sensitive to internals of cards and drivers. I have a case where some simple WPF programs render incorrectly on one modern, brand-new PC with a major brand high-performance graphics card and current drivers. The problems go away if I disable the graphics card (so it uses the integrated grahics). So I know it's the card or drivers. These programs render fine on several other older PC's I've tried them on.
As WPF programmers are there deployment strategies or programming strategies we can use to minimize the risks and exposures to stuff like this? If we can't count on WPF rendering properly on major brands of PC's and graphics cards what can we do? How common are issues like this with WPF?
Original post: WPF graphics card problem
If you are having hardware-dependent rendering issues, you can work around it by forcing software rendering. (In my experience, this has almost never been necessary; in most cases of video glitches, ensuring that customers have the latest drivers has solved the problem. As a WPF developer, I don't worry about this problem.)
If you're using WPF 4, use RenderOptions.ProcessRenderMode to force software rendering for the current process.
In WPF 3.5, your only option is to disable hardware rendering for all WPF applications on by editing the registry. Create/open the HKEY_CURRENT_USER\SOFTWARE\Microsoft\Avalon.Graphics key and create a DWORD value DisableHWAcceleration with the value 0x1.
For more details, see Software Rendering Usage in WPF.
I ran into a strange issue where "fn_key -- F4" combination on my hp laptop to extend the screen would stop working once I have a wpf application running. This happens even when I create an empty app -- as soon as I run it, I can't extend my desktop to a second monitor.
Thanks!
Sounds like an issue with your video driver. What kind of video card is it? Are you running the latest drivers from the vendor?
The problem was a driver issue (as Drew mentioned above).
To diagnose an issue like this, please follow the instructions from the MSDN article (http://msdn.microsoft.com/en-us/library/aa970912.aspx) on how to disable hardware acceleration and render everything in software.
Provided your issue is similar to what I have experienced, you will be able to single out the problem by adding the necessary registry key from the article.
We are implementing an application that needs dockable windows, similar to Visual Studio 2005/2008, but with multiple "docking sites", unlike VS's single one. Does anyone have a recommendation on a good library for this - either OSS or commercial? I am aware that Infragistics has one, as well as Divelement's SandDock and WPF-Dock from DevComponents, as well as ActiPro's Docking & MDI product. There is also one on CodeProject. Has anyone used any of these libraries? Was the experience good or bad? If you have experience with one of them, does it support multiple "docking sites"?
The one from Codeproject is the AvalonDock - we use it for more then half a year now, but we're far from release yet so we have the flexibility. Before ending up with AvalonDock we tried Infragistix, ActiPro, SandDock and may be some others.
Even though AvalonDock is not 100% bug free (well what is?) there are no major ones, it is very stable, fast and has all the functionality. It does support multiple docking sites.
Its an open source project and is in active development, so bugs are beeing found and fixed. Good experience so far.
I've been using the ActiPro library for several months and it's done me well. It does support multiple docking sites. The support is outstanding and you get some other controls (date picker, etc) that are missing from WPF. To me, for $150 it's money well spent. It worked out of the box, no fuss.
We used to use Divelements for WinForm controls but we think Actipro has better support, so we switched for WPF.
Just my two cents.
Don't forget AvalonDock on GitHub (part of WPF Toolkit). I've seen it mentioned in other places.
Initially I was going to use the ActiPro library (mostly because I am already using their ribbon), but I might give AvalonDock a chance since it is open source.
Anybody have any feedback/comments on AvalonDock?
I use DotNetBar, because it has ribbon/dock and more controls, and it's inexpensive. It's great.
http://www.devcomponents.com/dotnetbar-wpf/
SandDock is alright. We used it for a POC phase of a project. I found some pretty bad bugs in their layout saving mechanism. It generated XML, but then couldn't load this XML back; it threw an exception! I actually read through all the generated XML and had to write code to modify the XML slightly after each time it was generated. It did not seem like it was a well thought out design; I was hoping for common WPF base types like
Infragistics is a bit better but buggy. In fact, if you try running it on a machine that only has .Net 3.0 and no .Net 3.5, it doesn't work correctly. Have an outstanding dev issue with Infragistics and I don't know if they've made any progress on a fix for this. I've also had it crash a few times when floating a window and dragging it around (suspect this has to do with the .Net 3.0/3.5 issue above). I've found styling this control to be pretty un-intuitive.
I tried all the libraries listed here and they're all buggy to some extent. Although they are pricy I would recommend Telerik and Infragistics. Nevron merits a mention because their library is the best I've seen but it's for WinForms.
1 year later ...
AvalonDock is now stable and robust.
There's also an "AvalonDock wrapper" that simplifies working with it without reducing its possibilities.
See http://sofawpf.codeplex.com/
Here is another one:
http://www.essentialobjects.com/Products/EOWpf/DockView.aspx
This one has a number of built-in skins that you can switch dynamically. It also has many individual controls (such as a "Splitter" control) that you can use independently.
The explorer control in Windows Vista is very handy and I would like to be able to incorporate it in an application written in WPF. I've been unable to find a stock control that is part of the Framework. This application is being specifically developed for Windows Vista and therefore, having the same look and feel as the OS is desirable.
One could use the Microsoft.Win32.OpenFileDialog, but the problem with that is that it looks nothing like Vista's so it sticks out like a sore thumb.
Any thoughts on a good implementation would be most helpful. I would like to stay away from Third Party components if possible, but am definitely open to all suggestions.
Actipro makes a really good WPF breadcrumb control. There's also an open source WPF breadcrumb control that I might actually give a try.
I haven't yet tried it but look at VistaBridge... It gives you all the Vista look dialog boxes!
There is a replacement for the Microsoft.Win32 file dialogs on my blog that gives you the Vista look without the complexity of VistaBridge and is also backward compatible with XP.
http://www.nbdtech.com/blog/archive/2008/07/15/Vista-style-open-and-save-dialogs-with-WPF-without-using.aspx
At the risk of sounding self-serving, the best Breadcrumb control for WPF you can find is here:
http://www.teraque.com/Products/Explorer-Chrome-Suite
I've spent a year trying to reverse engineer the Window's Vista control because none of the off-the-shelf products provided the right look-and-feel. You will run into the limitations of all of the suggestions above sooner or later. And, having been through it myself, I can tell you that trying to embark on developing the controls yourself will take you months. The oddities surrounding the overflow logic alone will be enough to eat up two months just to get it right.
Good luck. If there's anything I can answer for you, please feel free to contact me.
Donald Roy Airey
Donald.Roy.Airey#teraque.com
If you are coding for the .net Framework 3.5, calling for the common dialog should display the correct Vista era dialog.
Sorry, appears I was mistaken. In previous projects, I was using this library to call the Vista dialogs.
My company is just starting to look at using WPF for migrating all of our 10 year old business applications. These applications will most of the time be running on computers that have limited/old hardware. We are now a little worried that the hardware might be too limited for using WPF.
We have installed Family.Show (http://www.vertigo.com/familyshow.aspx) on an basic older computer and that seems to run ok. But we would like know what your experiences with WPF on older hardware is? Anyone out there willing to share some experiences with us?
I would add several things:
The first is, as Stu said, it really depends on what you are doing. In particular, we have found a noticeable difference between WPF 2D and WPF 3D. If you are doing any WPF 3D stuff at all, your performance is highly dependent on the quality of the video card (see the Graphic Rendering Tiers link already mentioned). In particular, we released a WPF 3D feature in April of this year, and it really only worked smoothly on Tier 2 hardware.
Second, I would point you to Jossef Goldberg's blog. It has a wealth of information on WPF performance related items.
Third, I would grab and utilize the WPFPerf tools. They were recently updated actually. Jossef's blog post will point you in the right direction there as well.
Fourth, take advantage of virtualization wherever you can.
Finally, I would recommend monitoring performance all the way through the development life cycle. I think the story goes that originally the Blend team did not evaluate performance (for their first release) till closer to the end, and it made solving the problem much more difficult.
Update: There is another StackOverflow post on this subject. Just wanted to point others to it.
WPF apps will generally run no slower than their equivalents using other technologies. In other words, performance depends on what you're doing. If you have a basic app with some simple data entry controls and a grid or two then it'll be a lot less demanding than an app that has animated custom controls with overlaid video, etc.
You should also bear in mind that you must have at least XP SP2 to install WPF, which sets a reasonable hardware baseline anyway.
In summary you should have no problems running a WPF app on older hardware as long as you are sensible with the frills. Given WPF's templated controls it's also fairly trivial to test for a basic level of client performance at runtime (see Graphics Rendering Tiers) and only enable more advanced features on suitable hardware.