The official source of product insight from the Visual Studio Engineering Team
This is the first part in a seven part series. Links to the other parts are included at the bottom of this post.
Now that the Release Candidate for Visual Studio 2010 is publicly available, we’ve started receiving questions from inquisitive users about how Visual Studio 2010 itself was built. In particular, one questioner wanted to know if we were going to keep all the WPF “magic” to ourselves. Rest assured, the answer is a resounding “no!”. We want our users to be able to take advantage of all the WPF 4.0 “magic” in their own applications too. This is the first article in a series of postings which will present some of the tips, techniques and new features in WPF 4.0 that we use in Visual Studio 2010. Some of it is loosely based on a talk I gave at the Professional Developers’ Conference in Los Angeles last November.
One of the first questions people ask is “why did you choose WPF?”. Let me try to address that in a few different ways.
Since the release of the first version of WPF in .Net 3.0, customers have asked us at Microsoft “If WPF is so great, why aren’t you using it for your own applications? Which Microsoft products are built using WPF for real? How can we take a bet on WPF if Microsoft isn’t prepared to use it in their own applications.”
In the early days of WPF, these were fair criticisms and there was a fair amount of healthy debate about whether WPF was ready for large commercial or LOB (Line of Business) applications. At the time, probably the largest and most obvious example of a Microsoft application written in WPF was Microsoft Expression Blend and it certainly proved the platform as capable. Joining Expression Blend, were other products in the Microsoft Expression Suite and, without taking away any of their success, none of them had quite the reach that would convince developers to take a bet on WPF.
With Visual Studio 2010 and WPF 4.0 locked on the same schedule, codenamed simply “Dev 10”, we had a golden opportunity to prove that an application the size and scope of Visual Studio could successfully be built using WPF. The arrangement was mutually beneficial for both teams: Visual Studio got a powerful, modern UI layout and rendering engine; WPF got an enterprise-class product to showcase their platform. Along the way, the WPF team was able to fix important bugs and introduce new features to enable key missing capabilities to the platform and these benefits extend not just to the Visual Studio team, but to all developers building WPF 4.0 applications.
Another reason for choosing WPF was architectural. Visual Studio has a mature code base with some components rooted in technology going as far back as Visual C++ 6 and Visual Basic 5; well over a decade old. (For some history, if you have the time, you can read through Rico Mariani’s fabulously detailed series on the history of Visual Studio.) The Visual Studio long term road map calls for some features which will stretch the product into new areas that the current architecture cannot support. The architectural initiative in VS 2010 was not to move to WPF specifically, but to install a presentation neutral architecture which would allow us to decouple the core business logic from the presentation layer and give us the agility we need for future versions. As a technology, WPF leads naturally to this “separated presentation” architecture, often called “Model, View, Controller” or “Model, View, Presenter”.
Also, as plans for Visual Studio 2010 were being developed a number of teams declared that they were going to be building entirely new components using WPF. The most obvious one is the new Text Editor, but there were enough others (the new Architecture Explorer and graph viewer, tools for parallel debugging, for example) that we realized we needed to make changes to the rest of the shell in order to support WPF as a first-class presentation layer. There would obviously be some common code that they would all need to share in order to work well together.
All the ‘chrome’ in the IDE is handled by WPF. By that, I mean all the frames and adornments around the document and tool windows are part of the WPF Visual Tree. That includes the main menu, the toolbars, context menus and the status bar. The document “well” – indeed the entire window management system - is also WPF including the overlays which appear when rearranging windows by drag and drop. The new Start page is all WPF and, if you’re so inclined, you can write your own replacement Start page in XAML. I already mentioned the new Text Editor (capitalized out of respect for the fantastic work done by that team), which was built from the ground up using WPF. Using WPF in the Editor opens up opportunities for developers extending the Editor to create visually impressive extensions in just a few lines of code. Several other commonly-used text-based tool windows, such as the “Output” and “Find Results List” windows pick up the new WPF Text Editor too.
Other frequently-used windows such as the Solution Explorer and Toolbox were not converted. In fact, the majority of tool windows were not touched for this release. Partly this is due to time constraints (we simply didn’t have the time or resources to convert everything to WPF), partly because there’s no compelling need for it, and partly because we continue to support other presentation technologies such as Win32 and Windows Forms. Indeed, for some components, such as the Windows Forms Designer, it would be unnatural and unnecessary to convert them to WPF.
To see for yourself which pieces of the IDE are written in WPF, you can use the “Snoop” tool to inspect the WPF visual tree for Visual Studio. Make sure to use the latest 4.0 version and check out the cool 3D view to view Visual Studio like you’ve never seen it before!
Here is a list of WPF features, new for 4.0, that are used by Visual Studio 2010. I’ve probably forgotten a couple (hopefully nothing major). If so, I’ll address those in future posts.
That’s it for this introductory post. I have a rough sketch of other topics I want to cover, including “focus tracking” that I just mentioned. Part 2 will cover performance tips and some of the techniques we used to optimize the speed of our new WPF user interface. I’ll be inviting other team members to write about their contributions along the way, and we’ll probably return to performance tuning later in the series too. In the meantime, do please use the comments to ask those burning questions because that will help me shape the remainder of the series.
Other posts in this series:
Paul Harrington – Principal Developer, Visual Studio Platform Team Biography: Paul has worked on every version of Visual Studio .Net to date. Prior to joining the Visual Studio team in 2000, Paul spent six years working on mapping and trip planning software for what is today known as Bing Maps. For Visual Studio 2010, Paul designed and helped write the code that enabled the Visual Studio Shell team to move from a native, Windows 32-based implementation to a modern, fully managed presentation layer based on the Windows Presentation Foundation (WPF). Paul holds a master’s degree from the University of Cambridge, England and lives with his wife and two cats in Seattle, Washington.
I'm not sure this release served you well as a showcase for WPF. Here is how I see it: With access to WPF source code, a top notch team (including perf star Rico) and the ability to get changes implemented in WPF itself, you guys almost blew it on this release, largely due to WPF issues. In the end, Beta 2 was not good enough, you had to move your RTM date and go into overdrive to save things.
Should a smaller shop with less resources, less talent, less access to the source code and devs of WPF itself use WPF in a project? I wouldn't risk that.
Plus, keep in mind that this happened on a project that is essentially a fancy text editor ;)
Excellent! Thanks for this. I hope more to come, especially about WPF and its performance.
Also, I'd like to ask about new WPF toolbars. It seems there is one issue that size and position settings not properly or even not persisted. For example, the Debugging toolbar's size and position settings are not persisted when switching between editing and debugging sessiosns. Can you commment on this also?
Sounds like WPF really wasn't ready for prime time until now. Poor text rendering, poor performance over Remote Desktop, inability to create the main window hidden and inability to route commands without changing the input focus... those are very basic issues for a UI framework.
It's good that improvements have been made to it after a major in-house product switched to it but that "eating your own dogfood" should have happened in WPF 1.0 not 4.0. (Not neccessarily with Visual Studio but with more than just Expression Blend.)
IMO, Visual Studio and Expression Blend are still not selling WPF on me because they both look so non-standard compared to the rest of the desktop and the user's choices about window colors and themes/visual styles.
I hate the new VS2010. The text in the editor is horrible to read and after a few minutes working in VS2010 I get headache. When I switch to the VS2008 Window, my headache is gone after a few minutes. The text is brilliant smoothed and fine to read. This test issue in WPF happens since the early days of Avalon and if you don't fix this horrible text rendering, I'll never use it. Also the performance (measured with xperf) is still half of what I have in VS2008.
I think VS2008 will be my last VS (after using every version since VS6).
Thanks for your comments. WPF, as a technology, receives an unfair share of blame for undeniably poor performance at Beta 2. Because the WPF UI is the largest visible change since VS 2008 and because it handles most user interaction with the product, it's naturally where people aim their criticism. However, this criticism is largely inaccurate. While squeezing the best out of WPF takes some effort, there were other performance problems (memory, response time and scalability) in nearly all scenarios. Many of those other scenarios (solution load and build, for example) have very little UI. I think Rico's blog covers some of those other scenarios quite well but, rest assured, his blog just one view, not the extent of performance engineering on the Visual Studio team.
Should others use WPF in a project? Absolutely! We don't want to keep the WPF 'magic' to ourselves. The reason for this series of postings is exactly so people can evaluate WPF for themselves, understand what problems they might face, and learn from us how to leverage WPF in applications like Visual Studio.
The toolbar’s row (“band index”) and order within that row should be persisted. I played with it a little, but I have not been able to reproduce the behavior you described. If you believe there is a bug here, please use the “Report a Bug” feature on the “Help” menu and provide as much detail as possible. Thanks.
Thanks, Paul. I guess as a small shop deciding on WPF it really doesn't matter that much whether these VS problems originated from WPF, or the general move to managed... From the outside VS 2010 simply doesn't look that much different from VS 2008. So I get the impression that really the main driver of the problems was .Net/WPF, i.e. the move to this new stack. If I have little resources, I'm just not sure whether I can risk that move. Yes, maybe it will work, but there seems to be a decent chance that I will end up in the same situation as you guys did with Beta 2. For a small shop that would be the end. So, quite frankly, I think the proper advice for such shops is to wait until there has been a major project (like VS 2010) that just sailed to victory without any hickup that stemed from the .Net/WPF stack. I'm just not conviced that a rocky journey like VS 2010 sends the message "Go on, this is proven, working technology".
Thank you for your comments and I’m sorry you’re unhappy with the text in the editor. We have seen an upswing in the number of reports of blurry text in the VS 2010 editor since last week when the release candidate was made available. This renewed interest in the topic has been surprising, because the new Display mode based on DirectWrite was turned on for Beta 2 and hasn’t changed since then. We are still investigating these reports, but here’s what we know so far:
1. There are some very slight differences between ClearType as implemented in GDI (Visual Studio 2008) and ClearType implemented in DirectWrite (Visual Studio 2010). These differences manifest themselves most readily in the intensity of ‘ghost’ pixels used to smooth the edges of characters (glyphs).
2. Some people’s eyes are more sensitive to this difference while others don’t notice it. The switch to DirectWrite in Beta 2 eliminated the problem for many people, but there’s still a proportion of the population who find the text unusable. You can read more at http://en.wikipedia.org/wiki/ClearType (ClearType and human vision)
3. Some users report that blurry text can be improved by running the ClearType tuner in Windows Vista or Windows 7. Type “ClearType” in the Start menu to run the tuner.
4. Adjusting the brightness and contrast settings on your monitor may help.
5. Fonts need to be ‘hinted’ to work well with ClearType and some fonts are missing this information. Some fonts look better than others.
As I said, we’re investigating and we’ll post updates here when we have something to report.
Regarding the performance issue, could you please be more specific about which scenario is slower than VS 2008?
Hey Paul, great article, can't wait to read the other parts. We've been using WPF for a few years now for our game engine's world editor and a few other things all in one IDE like Visual Studio. So I'm really glad you guys bit the bullet and tried to prove the tech on an application as complicated as Visual Studio, which seriously is no small feat.
You guys got a good number of things converted over to WPF. But I must admit I grinned and then laughed pretty hard when I saw that the solution explorer's treeview was still Win32.
So I have to ask, did you guys struggle and fail at getting a multiselect treeview working with any measure of performance?
What improvements can we look forward to in .Net 4.5 based on your teams experience with WPF, (please say a real multiselect treeview, and I know you aren't on that team, but what improvements would you like to see).
"5. Fonts need to be ‘hinted’ to work well with ClearType and some fonts are missing this information. Some fonts look better than others. "
Consolas for the win :)
I for one would like an insight into the visual tree with special regard to the docking, floating and snapping aproach to the modular user interface.
At least for me, having worked to some extent in versions of WPF prior to WPF 4, implementing this kind of user interface would involve some pretty heavy lifting.
Thanks for your comments, Nick. The Solution Explorer was top on our list of tool windows we wanted to convert but didn't have time for. In fact the Solution Explorer is one of several other tree-based "hierarchy explorer" windows (Macro Explorer, Server Explorer, Team Explorer) that share a common implementation and converting one would have taken care of all of them.
It's too early to say anything about the next version of WPF, sorry.
Thanks for your comments, Rangar. That's a great topic, one which has been asked before, and we'll try to cover it soon.
I like the new Visual Studio 2010 IDE.
Is there a way in a WPF Application project to pass from tab Design to tab XAML and vice-versa using keyboard?
Thanks in advance.
Thanks for you comments. The command "View.ViewDesigner" has the effect of toggling between the XAML and Design tabs. It is not, by default bound to any keyboard shortcut in the WPF designer, however you can assign a new keybinding yourself. Go to Tools/Options..., then select Environment/Keyboard in the tree. On the Keyboard pane, type "View.ViewDesigner" into the "Show commands containing" search box. Click in the "Press shortcut keys" box and press the keyboard shortcut you would like to assign to this command. I chose "Shift+F7" to match the same functionality in the HTML designer. Click the "Assign" button and then "OK".
Now you can use Shift+F7 to toggle between XAML and Design view.
Your tip works well.
I thought by default bound to "Ctrl + Page Down" because in Web Applications has the effect of toggling between Design and Source tabs (Shift + F7 too), but it is not important, with you instructions Shift + F7 is ok.
Thank you Paul for your answer.