Visual Studio Dialogue with WPF Performance Emphasis


Lots of great comments on my last posting, I wanted to address the performance concerns especially.  I’m always amazed by the wide variety of opinions 🙂


First I’d just like to say that I didn’t suddenly forget all my performance religion when I took this job and I believe the developer division at large has discovered this 🙂  I’m trying very hard to drive good goals and culture and I think it makes a difference.  Of course I’m never satisfied but that’s par for the course in the world of performance management.


I’m just going to grab a selected set of comments here and try to address them pretty much in order.



The thing that miffs me with WPF is cleartype.  There’s not facility whatsoever to turn it off, from what I can tell and have researched, for WPF based applications.  This alone makes me worried to all heck about the future of my favorite IDE (and being a C# developer, this is even more important to me).



Please, please, please let me disable that mess that is cleartype.  For me, it isn’t clear, and gives me nearly instant eyestrain and headaches.


I’d hate to be forced to use fonts that don’t fit my needs as well just so that I can have some supposed “new and exciting” interface in an arena where I just don’t need it.  I’d wager that other developers don’t need to be graphically wowed by their IDE either.


[…]


Tuesday, November 18, 2008 7:24 PM by Steven Raybell


The cleartype concern isn’t one that I’d heard before I will see what I can do make sure we have good font choices there.  I expect we’ll have lots of skinning opportunities.


There is a really important underlying point here.  We’re not embracing WPF because we want graphical “WOW” — that wouldn’t be enough of a reason.  What we want is flexibility and extensibility.  For instance, it’s because the new editor is WPF based that we can, for reasonably engineering cost, offer the ability to add inline adornments, margins, even “heads up display” style extensions.  These are not just minor little toys or typical editor extensions you could literally change the way you work by extending the editor to include rich display of imbedded or related information.  I expect this to fundamentally change the way people think about code editing… the toy example showing reformatted XML inline with the text plus bug links was just the beginning.  The best part is you won’t have to wait for us to do these things — you want profiler information overlaid on your text?  No problem go do it;  Test coverage?  Hot links to documentation?  Online presence indicators based on email names in comments?  You could do all these things.



Rico,


Great article and great direction to take this excellent product. I love the idea of integrating azure like features. Buddy coding would be great. An integrated iphone like app store for VS extensions would be great for the various extension developers. 


I guess a few questions that tie in:


1. Will the new design of VS allow me, the end-user, to disable a bunch of features (because of the clean extensibility model) to such an extent that VS launches as fast as notepad and acts as fast as it? I know its not such a realistic example but I think it a really admirable goal.


2. Will the new design of VS allow me to better diagnose issues with visual studio. For example if my cpu suddenly jumps to 100% will I be able to find out that component XYZ is responsible, and disable it? I’m thinking something like Google chromes task manager ..


3. You did allude to API simplification on the extensibility side, I think this is fantastic, are you going to have the freedom to break backwards compatibility?     


4. In a tie in question, what improvements are you looking at around profiling and diagnostics, a tool like ants profiler baked in perhaps?


Again, great article and I think you are on the right track.


On a side, fairly insignificant note compared to all the rest. Will you be looking at providing proper support for developing MCML apps in VS.Net? (I’m tired of pushing xml around) I’ve advocated for quite a while that they should get rid of that technology and replace it with WPF but it seems not to be happening …


Cheers


Sam


Tuesday, November 18, 2008 9:50 PM by Sam


Lots of different questions here.  Let me pick some of these off, keeping in mind I can’t promise feature deliveries but I can tell you what I think about:



  • Azure based services are something I think about a lot, we’d be foolish to not include some kind of services angle to our product in this climate

  • I love the buddy coding idea, that’s another one I think about a lot

  • Launching as fast as notepad?  I don’t see how I’m ever going to pull of that miracle: editing tiny text files is not really the sweet-spot for the product but slimming down extensions is definitely something I want to do, even if we’re not as fast as notepad a diet is never bad thing.  Especially for our isolated shell offering

  • More user visibility of what VS is doing internally and management of long running tasks is another thing I think about, it’s longer term though

  • I am willing to “break some eggs” on the backward compatibility front — I don’t have the same iron-clad burden as say Windows does but neither can we go crazy.  Where we’re making changes we have to communicate them clearly and do it for significant benefit.

  • We have a profiler in the VSTS product line, many people have asked about putting it in one of the more affordable SKUs.  I guess all I can say there is that it’s normal for features to move down in time and this is a popular request.  But I definitely don’t make the “which feature goes in which version” decisions.  Sorry 🙁

  • I know basically nothing about MCML applications but I can tell you the long term strategy is that we need sufficient extensibility and separation of concerns that people like the Media Center team do not need to beg us to support their platform — they should be able to do everything they need with our basic toolkit.  Nothing else really has any chance of working — there are so many important platforms.


Wow. Rico, I think you’re the first person I’ve talked to in a long time that “gets it”.


So many people are on either side of the camp: either the


“go back to VC6 luddites/we don’t need no stinkin’ gradients” camp


or the


“don’t worry about how much resources we consume” camp.


Additionally, you’re not saying, “Hey, I’ve got a brilliant idea. Let’s rewrite the damn thing.” Instead, you’re taking the high road and doing a remodel.


I’m encouraged by what you’ve written in this post! And I’m really looking forward to Rico’s VS2010!


Tuesday, November 18, 2008 11:34 PM by JudahGabriel


Thank you 🙂  Everything in moderation. 



Moving over to WPF is fine if, and only if, it’s not at the expense of *any* end user experience/functionality.


Microsoft is famous for not getting 100% there and then saying “that’s as much as we could fit into a v1 release”.  Leaving any features that are replaced with WPF with reduced functionality is simply not an option.


If you can’t at the very least keep the feature set on par, then it’s absolutely not ready to be replaced with WPF.


Remember – developers are a picky and unforgiving lot!


Wednesday, November 19, 2008 6:25 AM by danieldsmith


Not any performance or any functionality?  No I don’t think I can promise that.  I’m sure, for instance, that in the smallest cases that we will take a startup performance hit to get things rolling.  But I’m being pretty ruthless about demanding savings in other areas so that overall for medium to large solutions I’m hopeful we can come out ahead.  That’s my goal anyway — I refuse to have the goal be parity.


Remember it’s not just about gradients or whatever, it’s about a whole new editing experience.  I believe this kind of deep extensibility is unprecedented.


The funny thing is, I think the general concern over WPF performance is perhaps misplaced.  It’s not that I’m especially concerned about the ability of WPF to keep up with our displays — I mean think about it, a typical editor screen-full if it one WPF element for every letter would still only be a few thousand elements, and of course it won’t be one per letter.  Importantly, the idea of creating a WPF representation of the entire text document is simply nuts (the document could be many megabytes under totally normal circumstances) so we must create just what we need for a screen-full. Once we do that, do we really think a few thousand glyphs is going to be a problem for that engine? 


But there’s more… it’s not like the old editor was this flawless creation, it had its limits and design choices too. It’s already sluggish on large files and not because of the drawing either.  The region management algorithms for instance (and every little thing you see that’s attached to text, from outlining to underlining, is a region) were quadratic in nature. The new editor has much better fundamentals.


So what am I concerned about?  We can’t use the new editor API universally, there’s just too much code to port, and we have other customers for that API —  so for them and for us we created a shimming layer that exposes the bulk of the old editors interface on the new editor.  But there are places where we have to emulate the old behaviors and those result in the old costs.  That’s a much bigger worry for me than WPF per se.  But it is manageable — after all, if it is really bad in some area we can always convert that to the newer API.



VS10 and WPF is the most exciting thing about VS, ever :), I’m sure WPF will be used for much more than a pretty UI, it will be used for a more functional and dynamic UI. Finally something that gets me over excited about VS10.


Wednesday, November 19, 2008 6:36 AM by Pop Catalin


You betcha 🙂



Hi Rico,


It’s great to see the emphasis on a more reponsible [sic] use of memory. Unfortunately, a lot of developers don’t care about memory usage and subsequently end up with applications don’t scale.


I agree with the WPF part. Using WPF as the graphics foundation for VS should definetely [sic] warrant a lot of focus for getting the best performance, features and scalability out of that graphics framework.


One thing that VS currently don’t do very well is managing really large files (e.g. XML files of 64 or 128 MB). It’s just not ideal to check these files for data using the IDE (other editors have better formance [sic] I’m sure, but I’d like to stick with VS).


Don’t forget to keep us posted 🙂


Wednesday, November 19, 2008 8:22 AM by Anders Borum


Accounting/budgeting use of resources has been a long time drive of mine.  It’s the cornerstone of good performance culture, nothing new there I guess.  But more people to convince 🙂


I know for a fact that the XML language service is getting lots of attention and I believe the new editor will be very helpful there.  I think you’ll be very pleased.



I don’t care about looks, but I can imagine lots of MS fanboys really need that.


Make VStudio responsive (like VC98 IDE) and scalable and I’ll be happy. I don’t really think you can achieve that with WPF in the product core. Good luck anyway.


Wednesday, November 19, 2008 9:10 AM by pingpong


I hope you’ll be pleased with what we produce.  Certainly I wouldn’t be doing this if it was just about incrementally improving the look.  Of course scalability is very high on my list.



IMO UI look is in a lot lower priority.


1. Performance


2. Extensibility


3. Low memory usage


4. Developer productivity


These are important to me.


I believe currently WPF is against #1 and #3.


Thanks,


Wednesday, November 19, 2008 5:15 PM by R.J


I’m sounding like a broken record now, but of course we’re not using WPF strictly to get a new look, although that is important too.   Just for comparison, the biggest source of memory usage in the system isn’t anywhere near the editor itself — the combination of language services (compilation+trees for intellisense), project system, and solution system take perhaps 10x the memory that editing does and they have limited visuals.  Ultimately WPF’s use of memory (assuming we don’t do stupid things) will be a tiny fraction of our overall consumption for large solutions.  Getting the main consumption sources down (by better memory allocation strategies for instance) is a much bigger deal.



You hit it on the right spot. IDE literally dies when working on files with > 5K lines.


Please do something to improve that horrible experience, generations will worship you.


Thursday, November 20, 2008 12:28 PM by Tanveer Badar


The new editor scales much better than the old editor.  But you don’t have to worship me 🙂   If you’re feeling very generous make a donation to your favorite charity 🙂 🙂



It’s great to hear the next release will focus on extensibility and more efficient memory usage.


However, i don’t see that much benefit in moving to WPF: “Do you really think GDI is the last word in computer graphics for the next 10 years?”


In all truth, VS2008 isn’t really that much ahead of my old Turbo C 2.0 as you would expect from 20 years of constant improvement, but I guess that there will be people who will drool on eye candy.


[…]


The startup is not the only pain point, please also consider shutdown. I typically run 2 or 3 instances of VS, and when I try to close one or more, I have to wait for a long time, until finally I get tired and kill it in ProcessExplorer. This is a common scenario for me and most of my colleagues, and there are many other places when users have to wait because of some seemingly innocuous operation.


And as someone already noted: allow me to turn off everything I don’t need, and tweak the environment to the way I prefer to work. That single improvement would make it worthwhile to move to VS2010.


Thursday, November 20, 2008 4:01 PM by zdeslav


I think you’re right that we still look a lot like classic IDE systems of the past.  I think we need to change that, there have been lots of improvements in the UX space that we should bring to VS.  But as I’ve written above, I don’t want to do this just to get eye candy.


If you want to know how I feel about shutdown you need go no further than this article — I’m pretty hard core 🙂


More use control of components, that’s goodness for the roadmap too.


I’m starting to feel like Don Quixote tilting at windmills to get all of this 🙂



“Do you really think GDI is the last word in computer graphics for the next 10 years?”


My response? “For IDEs? I sure hope so.”


Make it fast, make it scale, make it extensible. There’s still too much to gain in these areas to be bold about eye candy.


And I know I’m being unfair when I’m dismissing a potential move to WPF as “eye candy”, but the bar is very high if you want to create an interface that’s radically more usable than what we’ve already got. Which I hope would be the point of moving to WPF.


IDEs aren’t supposed to be wow material in the UI department, so what’s with wanting it to be “modern” in the first place? It should mesh well with the OS, but beyond that, anything that doesn’t translate to developer productivity gains is, IMO, a waste of human and technical resources.


I do see the benefit to MS for dogfooding their own UI technology in their flagship product, but that’s more a service to WPF than it is to VS, and as a backend developer I’m more than slightly biased against it.


Friday, November 21, 2008 4:06 AM by JM


I respectfully disagree with JM, except that clearly we do agree it shouldn’t be about eye-candy. 


We used to have real innovations in user experience in the IDE — pervasive tool tips, like in the debugger, docking windows, high quality customizable toolbars, and other things.  I think we should be blazing trails here too, in ways that are appropriate for a development environment.



Great post Rico, and great video with Paramesh on C9.


If it wasn’t for you being on the VS team, the news about WPF in VS10 would have made me weep.


I was *so* glad to see that Anders managed to get a dig in about VS perf not once but *twice* in his PDC talk. 


The current VS is shockingly bad for perf and I reckon 100M developers’ hopes are pinned on *you* Rico to get it fixed.   Don’t fail us, please!


Friday, November 21, 2008 3:02 PM by willdean


I love you guys.  *cough* no pressure *cough*


I do really appreciate your confidence…


I better not screw this up…



Speed.  100% this is my biggest gripe.  Asp.net solutions that take FOREVER to build and deploy and load, etc.


Do this for me, start filewatcher and then open a VS ASP.NET project.  When you see 1000’s of file open requests (duplicates in many cases) you will see the issue.  What about build – dont get me started – there are 10s of 1000s of file open requests, checking and most are duplicates.   The Hard drive is the slowest thing on a computer – so could you guys not figure out to use it as little as possible?


Friday, November 21, 2008 4:02 PM by Wayne



I strongly agree with Wayne. The best optimization that can be done is on speed, and most likely through better and fewer file accesses.


Friday, November 21, 2008 5:14 PM by Fabrice


I’m glad someone else mentioned one of the other big four resource usage sources.  And arguably the slowest.  Yes that needs attention too.



Great post and great suggestions in comments. Here’s my list (in order of importance)


1) Ability to disable clear-type!  [.. covered elsewhere ..]


2) Performance, performance, performance!


I can live with slow start-up, shut-down, or large memory usage. I really don’t need animations or much glitz; I’ll take it if it helps though. My #1 complaint with the current version is the ASPX editing (not the designer, I’ve given up on that a long time ago). It interrupts my flow all the time […]


However, it needs to be so good that I won’t even be able to know that it’s WPF based. If you can’t get the performance at least to the level of the current editor then please don’t even try. Thanks.


P.S. Have I mentioned performance?!


Friday, November 21, 2008 7:33 PM by Peter


I’m getting the message on clear-type options 🙂


I don’t think the WPF-ness of the new editor will help you here but it also has this great composable buffers architecture that should allow significant simplifications in how the ASPX experience works and hopefully that means hourglasses for you.


I like what you said about how it shouldn’t matter to you that the new editor is WPF.  I think that’s the right model for us.



Rico, your WPF reasoning sounds concise and may be even convincing, but you restrict yourselves down the same old path of “dogfooding new and cool windows technologies”.


Why don’t you take a shot at a paradigm shift for a change? Why don’t you hire 3-4 game developers in your team, experts in 3D, custom UIs and *performance*, and then build a whole new IDE that is NOT a windows application at its core but a DirectX “game”? I have seen mind-blasting UIs from game devs (not in the games themselves but in the dev tools for the games). I am sure you can find a couple of super-highly-talented game devs to add to the picture.


Warm Regards


Monday, November 24, 2008 9:55 AM by Dimitris Staikos


Well I like your way of thinking.  I’ve been trying to get people to think about creating “game quality UI” but of course we have to do that responsibly — we don’t really *want* to have 75fps in order to use the thing.  But the idea of having those great production values really resonates with me. 


But using DirectX, directly?  Could be issues there — like terminal server support for instance.  WPF is a pretty good compromise.  Remember, even games use a rendering engine to simplify their programming model.  You can think of WPF as our rendering engine, it helps with the kinds of compositions we want to do.



All I want out of VS2010 is for the RAM usage not to double.  I run a lot of IDE instances (I have 5 copies of VS2008 running now), and everytime I’ve upgraded to a new version of Visual Studio, I have to double the RAM in my machine.


VS2003 – 1GB


VS2005 – 2GB


VS2008 – 4GB


At the rate this is going, VS2010 is going to require a 64-bit OS.


Grrrr… I’ll be a corpse before I let that happen 🙂


Where’s my light-sabre!


What a great note to end on 🙂


Thank’s to everyone who posted and I hope this helps clarify how I think about things.  I really appreciate the high quality comments!

Comments (26)

  1. kfarmer says:

    It’s amusing to see all the comments that seem to imply WPF is just about glitz — yet sad that they seem to miss the composability points.

    True, WPF isn’t going to be as fast (yet) as old MFC.  But then, you could follow that argument eventually toward going back to command line editting, which some people to this day still do.

    WPF’s true strength isn’t that you can add animated gradients to use as brushes in rendering 3D meshes, or for that matter using 3D viewports as brushes for the same.  Its strength is, as you point out, the composibility which allows you to build sophisticated controls which much less spaghetti than before.  It’s not necessarily faster to build them, nor easier to build something functional, but it’s generally more tractable to build them correctly, which is a different and arguably more fundamental concern (function vs architectural compliance).

    And as for consumption, if the control is well-constructed, that’s much easier than before once you get your head wrapped around WPF’s world view (perhaps requiring some mild insantity).

    I have every confidence that this will prove by VS12 to have been the correct decision.  I’m not confident that VS10’s perf will satisfy the nay-sayers, and they’ll probably blame the WPF decision, but those same people aren’t the immediate target audience for this decision.

    I look forward to having more time to play with the UI as it’s fleshed out.  I’ve certainly spent enough emails toward the IDE team about feature ideas that this move enables. 😉

  2. Travis says:

    Hey Rico,

    A small(ish) feature request – what about using the DLR for scripting the IDE? Then we could hopefully use any DLR supported language to script the IDE.

    Along those same lines, it would be nice if /everything/ in the IDE were accessible. For example, I can remember trying in 2005 to create a Macro to change my coding style preferences (braces on newline), followed by a reformat, and I just couldn’t get to that option. This was a bit frustrating (but not a big deal in the grand scheme of things). Anyway, I’m sure there are plenty of issues like this lying around the place that could be cleaned up if you work towards it from the start.

    Thanks for your time, and I’m looking forward to seeing VS 2010.

  3. kfarmer says:

    Reformat-all-documents would be nice in general.  Especially if it were just a view, and didn’t necessarily save back (thereby applying your one-true-format over everyone else’s chaotic insanity.. you know how that goes).

    After all, why should spaces vs tabs matter, or where you place your braces, if people are usually using them to enforce their personal aesthetics?

  4. joewood says:

    Rico, I think you hit a point in this write-up.  We’ve hit an issue with WPF and remote desktops.  It’s a real show-stopper with the proliferation of virtual workstations.

    RDP doesn’t contain WPF primitives, and I don’t think there are any plans to.

    Is this a scenario that you’re testing and comparing against the (remotable) GDI versions?

    And please, add some pressure to get this fixed in WPF.  As originally promised a few years ago – we need MILCORE or DX primitives in RDP on all OS versions.

  5. bdodson says:

    Hi Rico,

    I’ll have to admit, when I first heard about the wpf editor earlier this summer, I shuddered, but now I’m totally on board and actually really excited. I’m going to have to try to figure out how to get my hands on some bits to start building extensions :-).

    On the subject of editing though, I’ve always wished I could use a non-monospace font in the VS editor effectively. The problem is that the spaces become so small that it’s very hard to read the indentation in source code.

    If VS would provide some type of setting that would be smart with the indentation spaces in code, I could use a prettier font. Perhaps the new editor already solves this.

  6. I think the complaint about ClearType is inaccurate. The problem is that WPF performs its own font rendering and is blurry whether ClearType is on or off. Expression Blend seems to have avoided this problem for it’s UI, but the applications it builds still have this issue by default. I’m not sure what the state of this issue is.

    See:

    http://www.paulstovell.com/blog/wpf-why-is-my-text-so-blurry

    and:

    http://209.85.173.132/search?q=cache:_Qcxu6f5eHMJ:social.msdn.microsoft.com/Forums/en-US/wpf/thread/5289ee56-6d06-4f66-84f2-69865b6dc401/+fix+wpf+fonts&hl=en&ct=clnk&cd=1&gl=us

  7. Miral says:

    It’s probably the fractional pixels.  All rendering coordinates in WPF are floating point, and WPF is normally quite happy trying to draw from one fractional pixel to another (and no doubt classic double precision rounding error plays a part here as well).  I can see why they did it (it supports dynamic scaling better), but I have no doubt it can lead to the blurriness problem.

    There is actually a property in WPF you can use to ask it to try to snap to "real" pixels when laying things out, that eliminates most of the problem — specifically, SnapsToDevicePixels (discussed here: http://msdn.microsoft.com/en-us/library/aa970908.aspx).  Sadly this seems to default to False, and many people don’t seem to know about it.  (Although admittedly this only has partial impact on text rendering.)

  8. Fowl says:

    Hopefully WPF starts taking advantage of Direct2D and DirectWrite.

  9. Stephan says:

    Performance and text readability are the number one problems for office-style desktop applications that make use of WPF. If you need any more confirmation of this fact, just search for these terms in your favorite search machine.

    Given the extreme difficulties everybody seems to have with developing a data grid control for WPF that comes close in performance to its GDI counterparts I have my doubts whether your optimism regarding the editor performance is well placed, though I hope you are right.

    The nasty thing about text readability is that it depends on human perception and display quality, which both differ from user to user. Sub-pixel text rendering, as employed by ClearType and WPF, seems to be a particularly polarizing issue: Most people like it, but a significant minority of users gets extremely irritated by color fringing and text blurriness. Since the text rendering in WPF can’t be switched back to the old GDI-style rendering, you are bound to severely annoy some of your clients.

    These problems will probably not be solved in a satisfying manner until WPF internally uses Direct2D and DirectWrite, which is not going to happen in the next 2-3 years.

  10. David says:

    Rico,

    I want to second Brandon’s conclusion about WPF’s poor implementation of ClearType and urge you to go to Paul Stovell’s blog entry for a deeper discussion. For GDI applications, I really prefer ClearType and think it is a great technology. However, WPF manages to make (small) text less readable than without ClearType, which can already be seen in the VS2010 CTP. This absolutely has to be fixed. I’m not that worried about performance (VS2008 is already almost as fast as Notepad to me). The blurriness is a big problem, though.

    I suspect that the WPF text renderer is more "general" and can handle fancy things like rotating text better (like we have seen in countless demos), but it has to get the extremely common case of ~11pt horizontal text on a 96dpi screen right. It doesn’t today, not even in .NET 4.0.

    Please tell me that the WPF team is looking into this. Not only will VS2010 be infinitely more usable if they do; people might actually start developing real applications in WPF once the text looks at least as good as GDI.

  11. Chris Nahr says:

    WPF text looks just fine on my 120 dpi screen, perfectly readable and virtually indistinguishable from ClearType.  I used to wonder if those blurriness complaints were just made up, or perhaps yet another example of rare hypersensitivity amplified by the Internet.

    So thanks for the Paul Stovell pointer.  His side-by-side comparison demonstrates that WPF font smoothing is in fact inferior to ClearType, although I still don’t think it’s such a big issue as all the hyperbole might lead you to believe…

  12. Stephan says:

    Re Chris Nahr:

    Please note that human perception isn’t a constant. The same thing will look differently to different people and some people are more sensitive to certain issues, not because they have a hyperbolic character, but because their vision/perception is more sensitive to these issues.

    Also, high density displays are far from being standard.

  13. pingpong says:

    Rico,

    Thanks for answering. I’ll remain a skeptic wrt to WPF. There’s something really wrong with this framework. Despite being hyped since 2002 and being released in 2006, there are virtually no serious WPF-based apps on the market. I watched the PDC keynote and I’m looking forward to see AutoCAD 2009, but otherwise the story is rather grim.

    Now you’re trying to fix the WPF problems _and_ use it to rewrite major pieces of VStudio. The entire scenario reminds me of Avalon/Longhorn coupling. We all know how it ended up. Still, I’d be happy to be positively surprised.

  14. Rico,

    Your series of posts are refreshing for their vision, clarity and transparency -kudos.

    I hope all your ideas get implemented because they sound awesome. WPF and the managed extensibility are the exciting things for me.

    One worry I have has been mentioned, the remote desktop dev visual experience. I do this all the time and couldn’t tolerate much of a slow-down.

    R# has become a mandatory tool for me these days. I’d like to see VS10 implement some of these ideas. Consumption first coding (where you write the code then use IDE to generate stubs) is invaluable. More features along this line would be tops.

    I’d really like MS to push the envelope, think outside the box, and er… take it to the limit, when it comes to refactoring in visual studio. It’s the only area my Java buddies proudly boast about.

  15. Skip says:

    I second the comments about WPF readability, but since blurry text seems to be a core property of the WPF technology I’m not sure that you’re going to be able to do anything about it.  

    But the main thing I’d like to stress is "please don’t remove functionality".   I’ll give you an example of what I’m talking about.    Back in the dark ages of MSC 5.1 and such, we did our debugging with codeview (and even debug.exe from time to time), and I was quite proficient with it.   I remember the first time I went to a technology demo of what was going to be released as visual c++ 1.0.   The tech evangelist demo’d the environment, and MFC, and promised us that all our development was going to be drag and drop.   When she asked for audience questions, my question was "Where’s my command window in the debugger?"   And how long before it finally showed back up?   A similar thing happened with visual sourcesafe.   In VSS 8.0 they removed the ability to just leave a file on a ‘get latest’ if the version you have locally isn’t readonly.   The option is still there on the dialog, but it’s greyed out 100% of the time.   As this is something that basically every single developer doing c# development will need (in order to have local copies of .config files), I had to wonder "did anyone actually use the product internally before making that decision?"   Of course, a quick and dirty c# app that finds the radiobutton and enables it fixed that for our shop, but long-term it could be a problem if we ever have to upgrade.   So please don’t remove stuff, even if you think nobody would ever use it, because there are probably a lot of us that do, and depend on it.

  16. ricom says:

    This WPF feedback is super valuable, thank you.

  17. ricom says:

    This WPF feedback is super valuable, thank you.

  18. Brandon says:

    I’m excited about the use of WPF in VS2010.  

    I prefer to have a dark background for my code editing and hope we can have the entire IDE have a dark theme like Blend now that WPF is being used.

  19. FKruesch says:

    I’m with Steven on clear-type / font anitaliasing. I like the crisp look with ClearType turned off and no antialiasing whatsoever.

    It’s a WPF thing. It would be nice to have a choice/alternative for text display.

  20. Adrian says:

    How well does WPF work over remote desktop?  Most of my work at home days involve hours and hours of using Visual Studio via remote desktop over a lowly 768 Kbps DSL connection.

    Thankfully, the current Visual Studio works pretty well this way (far better than the Office apps which seem to render everything offscreen).  If WPF is going to destroy this experience, you’re going to kill my productivity.

  21. int19h says:

    Regarding font antialiasing / ClearType in WPF – yes, this is a huge problem. It looks okayish on high-res small-size displays (such as those om high-end laptops), but on your average business or home desktop, the downgraded quality of WPF text is immediately visible. What’s particularly bad is that it is especially noticeable for system default UI fonts (Tahoma/Segoe) and sizes. So far, I haven’t yet met anyone who couldn’t spot the difference on 19" 1280×1024, and who wasn’t annoyed by WPF way of rendering text over stock GDI ClearType.

    Here’s the link to my MS Connect ticket on this, which in turn contains links to other notable discussions on this subjects around the Net:

    https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=380919

  22. Mike Dailly says:

    I have to say I have 2 real gripes about DevStudio. First is the real-estate that non criticle areas take up.Huge thick scrollbars, Tabs, boundrys etc. all mean less space for my source – this is very annoying. And if you happen to want a vertical split, most of the screen ends up gray. You should take the artist approach and look at the negative space. This should me minimal – DevStudio is all about source, so it should be the focus.

    The other is the response time when debugging. It used to be that you could debug very quickly but these days single stepping on a large project with lots of threads is a killer. You can actually be waiting seconds for it to step a single line sometimes.

    These aside, I’d also love to have better tools bars as 90% of the time I only use search, save and configurations.

    Mosty of all I guess I really need performance in the places it hurts us most – the GUI. if I click something, I dont want it to lockup for 5min at a time while it thinks about something.

  23. David says:

    A slightly different ‘performance’ concern here.

    On all the latest displays we are now LOSING vertical real estate, from netbooks going down to 600 pixels high, my notebook down to 900, to even the latest dell 24" displays dropping to 1080 from 1200 to be better for video playback.  The visual studio UI wastes a lot more vertical space than horizontal space (empty status bar, mostly empty menu bar, empty title bar for docked panes etc. etc.

    Could things be arranged (or better still ‘themed’) to switch that around?  Of course with WPF that should be a lot easier, switch the template for a docking pane so that the title and pane controls are down the left instead of across the top, or just a tiny icon overlay with popup in the corner since I don’t really need something to tell me my error list window is the error list window when it contains the error list which kind of gives it away..

    If the templates can be changed, will we be able to?  or just choose from some supplied ones like Blend?  In a similar vein, really hoping the new Windows 7 task bar will work much better then the current one if I have it on the side instead of wasting my ‘very scarce and valuable’ vertical space at the bottom.

  24. Jalf says:

    About ClearType, wouldn’t the obvious solution be "get it fixed, so it looks good everywhere"? I know that’s hardly the VS team’s responsibility, but having a technology that actually makes text looks *worse* for a significant fraction of the userbase doesn’t really seem like a big step forward. If it works that badly, doesn’t that mean the ClearType team has some serious work to do?

    Anyway, just one little comment about the "Do you really think GDI is the last word in graphics for the next 10 years" thing.

    No, but are you saying WPF is? Are you saying that Windows won’t natively support "the last word in graphics" for the next 10 years? That "the last word" won’t be available to native codebases?

    Nothing against WPF, but shouldn’t this be an ambition for the Windows team, to get the last word in graphics supported *natively* as part of the OS, with no separate products or API’s required? Doesn’t Windows look pretty bad compared to the competition otherwise? If all Windows itself can offer is GDI? (Of course Direct2D looks really interesting, but I don’t know if that is supposed to be broad enough to become the new "last word" for Windows, or if GDI will still be required in the general case)

    Again, of course, this isn’t really anything to do with the VS team, but it’s just what I thought when I read that sentence. 🙂

  25. [Dear Readers:I wrote a followup posting Visual Studio Dialogue with WPF Performance Emphasis based on

  26. Weekly digest of interesting stuff