The Roadmap for WPF

The Roadmap for WPF

Rate This
  • Comments 24

When we introduced WPF back in 2006 (.NET 3.0), the response was absolutely phenomenal. Enterprises, ISV’s, and Microsoft Partners have made the technology central to their business, building amazing vertical solutions and mission critical applications for their customers. This momentum carries forward to today – 10% of all newly created projects in Visual Studio 2013 over the past 60 days are WPF. WPF has amassed a passionate, vibrant, community that uses it to build data-centric desktop business applications on Windows. A recent example of this would be a new WPF application that was developed by our partners at InterKnowlogy. This application was recently used by CNN producers in the mid-term elections to upload, validate, and configure the data seen in the on-air election application. The election data is presented on CNN’s Magic Wall, which Microsoft’s Bing Pulse team helped to develop.

This post will address the roadmap for the WPF platform, including areas of investment we’re prioritizing and tooling improvements for upcoming releases of Visual Studio.

Areas of Platform Investment

Based on a survey we conducted at the //build conference earlier this year, UserVoice suggestions, and interviews with a large number of WPF developers across a variety of market segments over the past few months, we’ve prioritized the following areas for future investments to make WPF a better platform.

Performance: While WPF is actively being used to build large-scale, high performance applications like Visual Studio and Blend, further improving the performance of the platform based on customer feedback is a priority for us. Some key scenarios we are looking to optimize in this context are application startup, scrolling and virtualization performance of ItemsControls.

DirectX interoperability: The primary scenario of interest here is to make it seamless for WPF applications to interoperate with newer versions of DirectX.

Supporting modern hardware: Technologies like touch and high density displays are ubiquitous on modern devices. To support upgrading to newer hardware, it’s important that existing WPF applications can adapt to new hardware capabilities coming to desktop machines.

Tooling: We will continue to co-evolve the tools for WPF when appropriate, alongside new platforms like .NET/WINRT. This commitment is reflected in the tooling investments section of this post.

Investments in some of these areas might introduce dependencies on a particular OS version and/or have compatibility risks. For these cases, the features will light up based on the host OS and/or might require you to opt in to use the feature.

Current Progress on WPF

Let’s first address a common question regarding support: WPF is a quintessential part of the .NET Framework. The .NET Framework is defined as a component of the operating system, instead of an independent product. So, support for .NET Framework is driven by the support lifecycle policy of the Windows operating system. Extended support for the current recommended version of .NET (4.5.2) on Windows 8.1 is available till 2023. We will continue to fix security issues and bugs reported by customers that impact a large cross-section of our WPF customers.

Improving WPF quality

Work on improving WPF has never really stopped, and below are just a few examples of what you should expect to see in upcoming releases of Visual Studio 2015 and .NET 4.6.

Some examples of recent fixes in WPF which will be available in .NET Framework 4.6:

  • Multi-image cursor file support in System.Windows.Input.Cursor
  • Support for transparent child windows.
  • Improved double tap gesture recognition by using common threshold distance from registry.
  • Improved text selection through double tapping the WPF TextBox control.
  • Improved reliability of stylus input for the WPF ComboBox control.

 

We take your feedback to heart!

We are currently investigating a number of reliability issues and highly voted Connect bugs to address in a future release.

Title

Votes

WPF Touch Event Fires with Delay

29

WPF Ribbon Window: The border is too thin

18

Using BitmapFrame.Create with any TIFF file allocates 300MB of RESERVED MEMORY if Microsoft Camera Codec Pack is installed

12

Tooling Improvements

Tooling for WPF was a top customer request during our interviews with our customers and the surveys. This sentiment is reflected in the feedback on UserVoice, where 3 out of the top 5 ideas in the XAML tools category were either attributed directly to WPF or had users requesting WPF support in the comments.

Visual Diagnostics: The #1 request from the surveys and #2 idea on XAML Tools UserVoice was the need for an UI debugger for WPF applications. We are super excited to announce that we are building a whole suite of debugging tools for WPF apps that enable you to inspect the live visual tree and modify the properties of the elements while debugging. We will even enable you to persist these changes back to your source.

VisualDiagnostics3

Timeline Tool: An oft repeated request from our customers and the #4 request from the survey was better performance diagnostics tools for WPF. We are in the process of building a brand new diagnostics tool for WPF applications that will enable you to troubleshoot problems like slow application startup, poor frame rate and other common performance issues. Combined with the already available Memory usage and CPU usage tools, we will provide you with a complete toolset right within Visual Studio to build fast and fluid WPF applications.

Performance and Diagnostics Hub2

Timeline Tool Zoom

Blend Improvements: Blend for Visual Studio 2015 has been redesigned to remain the preferred tool for creating beautiful user interfaces for XAML apps. Blend has a sleek new look consistent with Visual Studio to improve the workflow between the two products. In addition, the new Blend is based on the same technology as Visual Studio (including WPF!) to improve shortcomings that Blend previously had, including a better solution explorer and source control support. More importantly, XAML IntelliSense and basic debugging capabilities are now available in Blend. One of the primary drivers for this investment was the support for asynchronous solution load and best in class version control that we could now provide for large WPF solutions that are common in enterprises. In-place template editing now supports WPF, and this experience has been further refined to enable true in-situ editing by using Peek in XAML.

Blend

The Timeline tool and Visual Diagnostics features are not currently available in Visual Studio 2015 Preview and team is working hard to get it out as soon as possible. This is just a sneak peek at the improvements that we are prepared to disclose for now. Stay tuned for more exciting news in the near future!

Tell us more!

We are interested in knowing more about what you think about our roadmap for the WPF platform and the tooling investments in Visual Studio 2015. Please send us your feedback through replies to this post, email, Connect bugs and User Voice requests.

clip_image006

Author: Harikrishna Menon, Program manager, Visual Studio Client Tools Team

Hari is a Program Manager with Microsoft, and works on the Xaml Experiences Team in Visual Studio. He has been with Microsoft for over 6 years, and has shipped multiple versions of Visual Studio working on a variety of XAML tooling experiences spanning different XAML platforms like WPF, Windows Phone and Windows Store.

Leave a Comment
  • Please add 2 and 6 and type the answer here:
  • Post
  • Why bother when all Scott Gu is talking about on the keynote for connect is Mobile first, cloud first (desktop last) or as it should be called IOS/Android/web first and windows desktop last.

  • Thank you very much! This is very important for us in enterprise, finance and LOB. Unfortunately cloud, mobile and web is not a silver bullet.

  • #OMG WPF! Really? LOL, this is best news this year from MS, AWESOME!

    thank you so much #Harikrishna , WPF has been exploding lately on its own, this changes everything!

  • Great to hear you mention performance at the top of your list. Sadly it doesn't sound like MSFT are acknowledging the architectural performance bottlenecks which are widely known by the community that make it almost impossible to get 60 FPS (or even 30FPS) in all by the simplest of visual trees.

    Is the performance tool going to get down to the level of DUCE (“Dynamic Unified Composition Engine") and below so we can see the inefficiencies of primitive rendering? It will be good to be able to show MSFT what inefficient use of even the most basic GPU is made by WPF.

  • This post is quite relevant. What has changed since 2006? paulstovell.com/.../six-years-of-wpf

  • This really isn't a "roadmap" more of a release notes and I think one needs to call that out clearly here.

    The roadmap is about showing you forward direction of a product or platform, in that what people really need to understand better around WPF's Futures isn't about the specifics of what each version has or hasn't in terms of both tooling and SDk breakouts but more so around its future momentum and where its likely to pickup or lose gains in the near future.

    Example. Today we are in a fragmented state of play, in which devs are still having to weigh up the decision matrix on what client-side solution to consider in adopting, and at times they are making informed & mature decisions around "Ok we'd like to be x-platform but if push comes to it, we'll double down 100% on windows initially" (especially in the enterprise).

    If these choices are made they'll likely either go down the Xamarin "Forms" route (when that eventuates) or adopt WPF as their primary choice. Great if they do the later, but here's where the core issue lies, in that WPF really is a Windows Vista/7 discussion today, in that you isolate your code base to the past instead of the future, whereby there isn't a strategy around how to move the code base from the old into the new (even small things such as UI namespaces for example compared to WinRT). So now there's this fork in the road around WPF old vs WPF new (WinRT Xaml Runtime).

    The roadmaps should be focused primarily on how to cover that issue of, with a strong emphasis on that if you write code today (fresh greenfield projects) your code can still be regarded as "fresh" for future WinRT / Surface story telling tomorrow.

    Failure to do so results in HTML5/JavaScript or Xamarin being the ones that takeover and whilst WPF is in somewhat of a caretaker mode from when I left it (i'd still argue strong its still in that mode) this may work to help shift the audience away from the platform strategically, it does not bode well for existing WPF solutions today as every day you sit in WPF there's an ongoing "question mark" over its head around "Is this still new or am i no different to a WinForms developer today, re-using legacy technology that has no future"

    That's your roadmaps primary goal here and i'm not seeing it.

    As a former Prod Mgr of WPF, thats what I'd have said to your team before this went out... "Who are you talking to and what is the goal here?"

  • Great news! I like to hear that you really read the bug entries on Microsoft Connect.

  • @Jack Ukleja: The primary scenarios we are focusing on the initial release is Layout, Render and Composition. Out of the three, We will drilling into Layout the most with detailed costs for each element in the tree. We appreciate your feedback and we will definitely look into enhancing the composition story in diagnostics tools further.

  • Any hope of .NET Native for WPF? Seems like that could have a huge effect on perf. But with the wide variety of desktop hardware, I don't know if that's just a pipe dream.

  • Thank you for remembering WPF. That is indeed a rare occurance.

    However, as Scott Barnes notes, this is in no way a roadmap. There plans here beyond the immediate next release. And speaking of that, 5 bugfixes. Really? Do you only have one developer working on WPF or what?

    All I get from this post is that you're keeping WPF on life support until 2023 with 0 new features and a couple of bugfixes. Now, if WPF was perfect, that would be no problem.

    Unfortunately, WPF is not perfect. Far from it, in fact. Now that XP is finally gone, can we please ditch DX9 and use Direct2D, which seems to be tailor-made for things like WPF? And basic mistakes like styling buttons wrong on Windows 8. Really? You couldn't spend 5 minutes creating the proper style? And you haven't fixed this in TWO years.

    The only thing that keeps me using WPF is that VS is based on it, so it is probably going to keep being updated, at least minimally.

    What we all want to know - is WPF the next WinForms - a dead platform hanging around in a limbo?

  • So finally someone from MSFT got to the helm of a dusty WPF  after all the other developers in the division got fired or move to Google. Congrats! Lets hope you are still around at MSFT not Google (Robots and Driverless Cars think future!!!) till 2023.... when the Extended support for the current recommended version of .NET (4.5.2) on Windows 8.1 ends or whatever that means! and as if it means a lot to anyone....

    Please fix your WPF rendering system to modern hardware..etc. Not everyone programs games anyway but that not an excuse after these years of neglect (chasing apple/surface sigh!)

    jeremiahmorrill.wordpress.com/.../a-critical-deep-dive-into-the-wpf-rendering-system

    and what are these guys doing here ??? below

    blogs.msdn.com/.../introducing-win2d-gpu-accelerated-2d-graphics-programming-in-the-windows-runtime.aspx

    bits and pecies here and there... CAN'T YOU PEOPLE WORK TOGETHER AND BRING IT ALL OUT FOR MODERN HARDWARE...

    OH Sorry whats was that again modern hardware....didn't here anything cause we were chasing Apple,Google and putting all the stuff on the Cloud...and buying some Phone Company....and creating our own Modern Hardware Surfaces and Pixel tables ....what you mentioned above is not a road map its an excuse to hang around MSFT till 2023 when the Extended support for the current recommended version of .NET (4.5.2) on Windows 8.1 ends or whatever that means! and do NOTHING collect your paycheck and join Google!!!

    ROCK ON DUDES !!! ROCK ON DUDES !!!

  • @Rob Hughes : Thanks for the feedback Rob, this is something that is on our radar.

  • Q: Is WPF the next WinForms (a dead platform hanging around in a limbo)?  

    A: No, its the new Silverlight (a dead platform hanging around on Windows 7 and below - the lions share of the windows eco system).

    Q: Is it worth investing in Windows?

    A: Only if you take the same tactic Microsoft took with office and release on every other platform before bothering with Windows.

  • First of all let me say "Thank You" for your efforts. This is good news. Like Rob Hughes I'd also like to see .NET Native work with WPF.

    A quick observation: working on the WPF team at Microsoft must be the most thankless job there is. You listen to an endless stream of complaints about how there is no WPF feedback or enhancement, but then when you provide these things you get a comments section peppered with sarcastic, childish and whiny remarks.

  • This is very encouraging !

    Especially since DirectX and improved performance is what I need :). The UI debugger looks awesome too !!!

    I've to say - I'm impressed....not only with the WPF stuff but with your tool fireworks (VS 2015), .NET core open source and so on in general. You guys simply build the best dev tools and runtimes. Period.

    Keep it rolling :D and ignore the people who complain regardless what you're doing ;)

Page 1 of 2 (24 items) 12