Description

I caught up with the great Rico Mariani, Visual Studio's Chief Software Architect, after his keynote at a VS partner conference held on the Microsoft campus.
He tells us all about the improvements in
Visual Studio 2010 Beta 2. Rico and team have taken the performance and reliability of Visual Studio to new levels in this release. Gone are the days of synchronous assembly and COM component reference look-ups (woo hoo!!!). Gone are the long start up times.
Gone are roughly 90% of the performance bottlenecks that slowed down the development experience inside the VS2010 Beta 1 IDE. The Visual Studio development team worked their tails off to improve perf and reliability across the board. Tune in to learn about
what they did and what they will do prior to RTM. Truly excellent engineering goes on in building 42. Well done, team!

If .NET 4 runs on XP at all, then I think it's safe to assume they merged the DirectWrite text rendering engine into WPF so it's available everywhere .NET 4 is. Would kinda suck otherwise, although I can't confirm either way.

Anyway, Lord of Visual Studio... I'd watch that! I mean it couldn't be any more dull than Lord of the Rings was.

Thats kind of what I'm hoping, the DirectWrite presentation at PDC last year was great, but I was kind of disappointed with the lack of support for XP and Vista (though I understand Vista support is in the works). If .NET4's implementation of WPF exposes
parts of DirectWrite, then thats great... if DirectWrite will be available to native coders on XP, even better...

DirectWrite always struck me as more of a library than an OS dependent feature. Being able to treat it like a library and use the same code path for all text rendering (even if it just falls back on GDI for XP under the covers) would have been very useful.

At any rate, its good to hear that this fix works on XP as well (though I should hopefully be running windows 7 at work by the time Dev10 is released)

Wow, the perf difference between beta 2 and previous builds is like night and day. I'm so glad Rico has been on the case - I'm not sure if anyone else could have pulled this off in quite the same way

If you're reading Rico, sorry to have previously given you such a hard time nagging about performance / features loss with the new shell. A lot of areas feel faster, and I'm really pleased that the switch to the WPF shell hasn't resulted in the loss of
any major features. In fact we've gained a number of great new editor features, and WPF itself has benefited from the whole dog fooding process.

On a side note, I like to have posted this on Rico's blog, but there seems to be an issue posting comments to all msdn blogs at the moment. Obviously some people's comments are getting through but I've spoken to a number of others who are completely unable
to post comments (roughly since the time the captchas were introduced). Can anyone look into this?

Also, for the "Add Reference" dialog, what's wrong with building a cache of the "nightmare tab" and .net tabs when you install VS 2010, and then have a refresh link on each tab for when you want it refreshed?

The projects and recents tab I could see being refreshed with each dailog load, but it's not that often that many people install components on their system which justifies a refresh for each "Add Reference" request.

I love that you're referring to it as the "nightmare tab"

p.s. I haven't seen Beta 2 yet, so if it's there, you guys are awesome...

One interesting thing that was talked about was intellisense and JavaScript. Would it be possible to implement intellisense for the DLR so all dynamic languages could have it?

You talked about how now almost all C++ developers finally use VS, it would be great if for the next major version (VS 2012 or something) you could have as a major target to get all the dynamic languages people to use it. With a great story for DLR intellisense,
form designers (perhaps have a xaml format for winforms that all languages can hook into, and ditch the code generation?), dynamic compiling, repl, etc.

In the pre beta2 days, wpf didnt snap rendered pixels to device(screen) pixels when rendering text, so if you had text with a font that where only like a pixel wide, it could be renderd "between" pixels on the screen, this resulted in a blurry text much
to the dismay of wpf users.

using fatter and larger fonts would help, and it would also depend on your monitor, but the text didnt look its best, i think there was a pdc talk about direct write that explains the problem a bit more

cant wait to watch this one through, perf in b2 is really awsome and it looks great rico is the man indeed.

id also like to bump robertLs question, if js intellisense will be available for all dlr languages, it seems somehow logical that it should, but you never know

It's nothing wrong with that, it's just not as easy as you think. Consider that what you see in the Add Reference dialog needs to be filtered based on what your project is targeting, as Visual Studio supports multi targeting, now put that in a context when
a user has it's own subset (say a Mono profile) that needs it's own filtering, also consider that user subsets can be chained together (like 3.5 is to 3.0 and 2.0, that's why you see 2.0 - 3.5 assemblies when you targeting 3.5), and the whole problem gets
way more complicated. It's achievable of course, but not for Dev10 (IMHO).

So, if DirectWrite got embedded into WPF4, how about Direct2D? You're halfway there! My biggest beef with WPF performance is that it doesn't scale well with lots of 2D graphics objects (i.e., > 1000). It's possible to use light-weight objects like
StreamGeometries to make things a little better, and there are a few other hidden tricks we're finding. I'd like to try a Direct2D surface on a D3DImage in WPF4 (apparently there's a code sample for this being worked on somewhere), but ideally, WPF4 would
just scale nicely with lots of objects!

Sorry, I don't think I was specific enough. If there was a "D2DImage" ImageSource object in WPF4, that would work really well for now. We could directly render all of our unmanaged objects into the WPF container without creating any corresponding WPF objects
that have the architectural overhead you mention. We wouldn't have to deal with WPF air-space issues. And we would have support on XP, Vista, and Win7 (assuming that "D2DImage" includes Direct2D software rendering on XP).

Ultimately, though, they need to improve WPF's architecture to make it a more efficient retained-mode graphics system that can scale with large numbers of objects. I hope that's high on the priority list. In the meantime, improved interop with Direct2D
would be very helpful.

You can do that. Direct2d will render to a D3D surface so you can use the D3DImage to composite the results into a WPF interface. There are also managed wrappers for Direct2d in the
Windows API Codepack that was announced a while ago.

I haven't tried it, but my understanding is that D3DImage is based on D3D 9, while Direct2D is based on D3D 10.1, so while it's perhaps possible, I'm not sure it's straightforward. I'd like to see a code sample before digging in. Also, the Windows API
Codepack is only Vista / Win7, not XP, so I'd have to use something other than D2D on XP.

I'm still reading this thread so feel free to comment on the video, the beta, the history series, or pretty much anything else you'd like me to see. I'll do my best to make sure the right people get the message too.

I can't underscore how valuable the previous feedback was in ensuring that the right problems got focus. There's nothing like saying "look I got about 100 niners telling me what a POS the addref dialog is so we can dispense with the 'is this really a problem'
part of the conversation"

Even if I already know about the problems your comments are ammunition for me so please give me the straight stuff.

Well, now that you mention it. It would be good if plugins were never allowed to block any UI. It appears that sometimes in VS2008 you click the "Tools" menu, or right-click a project, or something it takes many seconds (~2-10) to open. I suspect it's one
of our plugins misbehaving for some reason, but it would be better if VS basically loaded any plugin UI asynchronously. So maybe that Incredibuild menu item isn't there initially if it's not fast enough (say, 50ms), that's better than its slowness getting
in my way the 99% of the times when I'm not actually going for that menu item.

DataSet viewer is not working when used in an application targeted at .Net 3.5. Not that it's that bothersome, but Rico promised excellent side-by-side functionality . The error says something about the visualizer not loaded due to different runtime.

Who's brilliant idea was it to remove support for raster fonts from the VS 2010 editor? They've been supported from the very beginning of Visual C++. How can you compare a font like Consolas or Courier New to a raster font like Terminal for visibility, legibility,
and maximum lines per screen, especially at small font sizes (e.g., 9 points and 6 points)? Try comparing these fonts in VS 2008 and tell me your opinion.