Hi, I’m Dan Chartier, I work on the Web Tools designer and helped improve its performance in Visual Studio 2010. For some background, Visual Studio 2008 completely replaced the original trident (Internet Explorer) designer with the FrontPage designer (which is also used by Expression Web). While we gained many improvements with this change, we received customer complaints about various performance problems that we wanted to address in 2010.

In general, the designer is quite fast.  This is especially true when editing pure HTML documents, which is what it was originally designed to do well. However, the designer edits more than HTML.  It also has the rather sophisticated ability to edit ASP.Net pages containing various interesting web controls and master pages. It was in these scenarios that most customers reported performance problems. Most of the pain points related to design view fell into one or more of these categories:

• Selection performance. Using the arrow keys or the mouse to navigate and select controls in the designer was too slow.
• Typing performance. The time between key strokes was too slow.
• Property grid performance. The property grid took too long to “synchronize” with the design view selection.

The third scenario might seem like a special case of the first, but because of the nature of the property grid implementation (it is part of the Visual Studio IDE, and when in design view requires relatively expensive reflection to populate itself accurately), it was a separate fix from the other categories.

Let’s take a look at these issues in more detail, and what was done to improve them.

Selection Performance

We received reports that selecting controls in the designer was extremely slow. The first thing I needed was a page or web site that reproduced the issue. After gathering sample pages from customers exhibiting slow selection response, I ended up using a page similar to the one below for profiling and measuring:

This page is actually not that complicated, and I can see why many customers would experience similar performance issues in their own work. Some key characteristics of this page are that it’s a content page with several nested regions (i.e. a content placeholder containing an update panel containing a panel).

Clicking back and forth between the two drop lists was, in fact, extremely slow (many seconds). The profile data revealed a few problems:

• When changing selection, the designer was repainting the same elements multiple times.
• The designer’s back buffer was getting created and released on every redraw.
• Feedback UI (e.g. the labels and colorful rectangles drawn by the designer) took a long time to draw.

Without going into detail, it was very common for the designer to repaint elements of the page multiple times between redraws. This was a direct result of how the designer implemented incremental painting. An overhaul of how we incrementally painted eliminated this problem and gave us an impressive 60% reduction in selection delay.

Fixing the back buffer problem was pretty easy, and gave us another easy 15% reduction in selection delay.

Even after the incremental painting overhaul, feedback UI was showing up too much in the profile data. Specifically, the designer spent a lot of time painting region borders and label feedback. What I found was that it is pretty easy to reproduce a situation where the design has a fair amount of UI to paint. Here is an example:

Simply nesting three panels required the designer to redraw all three region labels, the UI activated selection border and the region border, just to draw a selection change. It might not sound like a lot, but the labels are actually gradients, and drawing dotted borders in GDI+ is pretty slow. To reduce the amount of time we spent drawing design view feedback, I made some changes to how much UI we render and how we render it:

Design view now only draws one control label regardless of how many nested regions you have (it was actually a bug that we drew more than one) and the region feedback was changed from a dotted blue rectangle to an alpha blended grey one. This significantly reduced the amount of time spent painting with GDI+ and made the UI consistent with how we draw feedback for HTML selection.

For reference, after these changes, the page I showed above looks like this in Visual Studio 2010:

I think the result is cleaner and, best of all, much faster! Selection delay in the profiling page was reduced from several seconds to fractions of a second. I think most customers will experience similar improvements if they are running into frustrating selection delays.

Typing Performance

Typing was by far the biggest design view complaint we received in Visual Studio 2008. Most of the issues involved editing inside of ASP.Net regions, which are inherently more expensive since we need to round trip edits back and forth to the control designer. We made a fix in this area in VS 2008 SP1 (essentially delaying control designer updates until idle) but it was scoped to only one scenario. The selection performance changes made some small improvements in typing delay, but after our experience with 2008 we really wanted to improve this area as much as possible.

In Visual Studio 2010 we made a lot of changes to improve typing performance in design view, particularly when editing inside of HTML tables (many controls with regions use tables in their design time HTML, which made incremental table layout part of the editing scenario’s critical path).

I won’t go into much detail, but by improving some key data structures in the designer, we were able to reduce the typing speed delay in our internal typing scenario (a relatively complicated multi-region page) by about 50%. Generally, you should see typing be at least as fast as your keyboards typematic delay (~200ms).

While we made some great progress, there are a few cases where you could still see the designer lag:

• If typing causes large layout changes, such as typing within an auto-sizing table, it will be slower as the designer needs to re-layout parts of the page, potentially per keystroke.
• You may still see a delay when the designer round trips your edits to the control designer, this is currently unavoidable, but only happens on idle (which is ideally fired after you’ve finished typing).

Property Grid

Many customers use design view as a convenient way to change properties on their controls. In some cases there would be a noticeable delay between selecting an element in design view and the property grid synchronizing to that selection.

In Visual Studio 2010 we now refresh the property grid immediately after selection change in most cases. You should see a noticeable improvement if you ever ran into this problem in VS 2008.

I hope this helped you understand some of the work we did in Visual Studio 2010 to make design view a faster, more efficient tool. Feedback is always welcome. Please feel free to leave your feedback through Blog comments, the MSConnect Feedback System, or contact us through vsweb-AT-microsoft-DOT-com.

Thanks,
Dan Chartier