Design View Performance Improvements

Design View Performance Improvements

  • Comments 5

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.

Dan Chartier

Leave a Comment
  • Please add 1 and 4 and type the answer here:
  • Post
  • thanks for good information and i would like to adapt with my program

  • This significantly reduced the amount of time spent painting with GDI+ and made the UI consistent with how we draw feedback for HTML selection.

  • Hi Dan.  One big problem I have with the web form designer is that you STILL can't select multiple controls in design view and drag them with the mouse or nudge them with the keyboard.  It's been years since you replaced the wonderful, fast and truly WYSIWYG IE trident designer with the frustrating and not-at-all WYSIWYG Front Page designer, and you still haven't implemented this basic feature.  Not having the ability to drag/nudge/resize multiple controls simultaneously is very frustrating for designers who use absolute positioning.  I had really hoped you would have re-implemented this basic missing functionality in VS 2010, but you haven't.  Visual Studio 2005 had this feature down perfectly, why is it so hard for you to get it working in Visual Studio 2010?  It's not like you haven't had the time or heard the constant customer complaints about this.

    If you're not going to pay any attention to this issue, could you at least give developers the OPTION of using the IE (trident) designer in our projects instead of the Front Page designer?  I would love to take advantage of all of the new code-behind goodness offered in VS 2010, but I'm stuck on VS 2005 because of the incomplete/innacurate Front Page designer.

    People who like to spend all of their time in the HTML source and do all of their designing by typing text probably like the Front Page designer.  But for designers like myself who like to design visually with drag-and-drop and absolute positioning, the Front Page designer has been a huge step backwards and a big let-down.

    Please either implement the missing functionality in the new designer or give us the option of using the IE (trident) designer for those of us who like it much better.

  • Hi again Dan.  Another bug in the designer is that textboxes always render at runtime wider (by about 4px to 5px) than they are shown in the form designer. VS 2005's form designer did not have this problem.

    You can try an experiment to verify this.  Create a form with three absolutely positioned TextBoxes, each with 136px width, all vertically aligned but leaving about 5px of horizontal space between them. Set their border widths to 1px and their border styles to Solid.

    No run the page in IE, Firefox and Chrome.  Notice how the rendered page looks the same in all three browsers, but looks completely different in the web form designer.  The 5px of space you left between the textboxes in design view is gone, and the textboxes are right next to each other at runtime with no space in between.  Each textbox rendered about 5px wider than it appeared it would in the web form designer.  It rendered this way in all browsers; the form designer is the odd-man-out.

    Again, the IE (trident) web form designer in VS 2005 did not have this problem.

    Also, this issue appears to only affect TextBox controls.  Labels, drop-down lists, etc., always render at runtime with the exact same widths they appear to have in design view.

    You can verify this by putting 3 absolutely positioned labels onto the page same page in the first example, each one directly above one of the textboxes, and set their widths to exactly the same widths as the textboxes.  Set their border widths to 1px and their border styles to Solid.  Now run the page.  Again, your results are consistent across browsers but completely different than what you were shown in design view.  The labels rendered properly, the TextBoxes rendered too wide.

    Nothing you do to the border/padding/margin settings of the textboxes corrects this issue.  It is clearly a bug in the designer, one that has persisted and made my life difficult since VS 2008.  It's another reason that I'm begging you or someone on your team to put some time into the web form designer to bring it up to par with the capabilities and the WYSIWYG exactness of the IE (trident) designer in VS 2005.  Or at least give us the option to use the IE (trident) designer for those of us who need pixel-for-pixel accuracy in design view.

    When you are using the CSS positioning attribute "absolute", you expect that what you see in the designer is going to be "absolutely" what you get.  Currently, for TextBox controls, it is not.

    Thank you.

  • We actually didn't have any multiple selection support initially in VS 2008 (the FrontPage designer just didn't support it). As I recall, we added basic multiple selection support in VS 2008 SP1, but didn't implement the resize/positioning or the old alignment tools.

    It's unlikley we'll give you the option to use the old trident designer, it would take a lot of development and testing resources that could be better used for fixing and improving the current designer. I can't promise anything, but we'll probably implement multiple selection resizing and positioning in either SP1 or the next version of Visual Studio. That feature is certainly high on our list of customer requests.

    The textbox box-model issue is a bug and should be fixed in SP1.

    Keep in mind that even though the FrontPage designer has some shortcomings, it has many improvements over the old designer. VS 2005's designer was just a fork of the IE 6 browser, the current designer actually has better HTML 4 & CSS 2.1 rendering support. The new designer also has better layout tools and code preservation.

    I really appreciate the feedback, it genuinely makes a difference in our product.


Page 1 of 1 (5 items)