Welcome to Pete Brown's 10rem.net

First time here? If you are a developer or are interested in Microsoft tools and technology, please consider subscribing to the latest posts.

You may also be interested in my blog archives, the articles section, or some of my lab projects such as the C64 emulator written in Silverlight.

(hide this)

Windows Client Developer Roundup 059 for 2/14/2011

Pete Brown - 14 February 2011

Happy Valentine's Day!

This is Windows Client Developer Roundup #59.

The Windows Client Developer Roundup aggregates information of interest to Windows Client Developers, including WPF, Silverlight, Visual C++, XNA, Expression Blend, Surface, Windows 7, Windows Forms, Windows Phone, Visual Studio, WCF RIA Services, sometimes even a little jQuery and HTML5. I also include fun non-Windows client tech like the .NET Micro Framework. If you have something interesting you've done or have run across, or you blog regularly on the topics included here, please send me the URL and brief description via the contact link.

WPF and Silverlight General

Windows Phone 7

XNA, DirectX, and GPU Programming

Netduino and .NET Micro Framework

Deployment

Visual Studio 2010 and .NET General

Visual C++

Fun

                   
posted by Pete Brown on Monday, February 14, 2011
filed under:                    

9 comments for “Windows Client Developer Roundup 059 for 2/14/2011”

  1. Oliviersays:
    Hi Pete,
    About "A Critical Deep Dive into the WPF Rendering System" I feel unconfortable.
    First, it sounds a bit like the paper of someone who _was_ a WPF fan but that has been fired (from MS, from MVP, from ... ? dunno). Kind of bitterness, just a feeling of course.
    Second, on a technical point, I think performances have always been "the" problem in our profession ! Not something new...
    Of course, WPF and SL seems to be not well optimized when it comes to deal with intensive graphic activity. It is a bit a shame since these environments are dedicated to create "UX oritented" application.
    So, there is some place for improvement, surely.
    But the question is not there, as I said it, performances have always been a problem in our profession. The real question is "are the performances of WPF and SL good enough for the vast majority of the applications ?".
    I think the answer is Yes.
    So, better performances ? of course, we need them, even in 50 years people will speak about getting better performances ! But performances are not a real problem with WPF and SL.
    What is annoying with this paper is that the subject is not "here is how WPF is working", a possibly interesting technical paper, but "look how bad is WPF !", bitterness and treason, and then it fails on the technical argument part.
    Of course just my feeling (and expressed as best I can in English that is not my mother tongue !)
  2. Kelly Sommerssays:
    The blog post "A Critical Deep Dive into the WPF Rendering System" By Jeremiah Morrill is an excellent post.

    As a cross-platform developer Microsoft provides the best tooling in my opinion however they don't translate to the best user experiences delivered to the end user.

    Both WPF and Silverlight don't perform well enough in comparison to it's alternative platform competitors.

    Cocoa performs better on a single core ARM 612mhz device (because it actually leverages the GPU substantially) versus WPF or Silverlight on quad core monsters. This includes Windows Phone 7 which has horrendous performance issues in Silverlight.

    A 612mhz ARM single core device should never destroy a desktop toolkit in graphics performance. Something is very wrong and hurts developers abilities to deliver rich user experiences that also offer world class input responsiveness.

    I think Jeremiah's post breaks it down pretty well. It's key for people like Jeremiah to speak the truth. The Microsoft ecosystem that only lives and breathes Microsoft doesn't help give proper feedback to Microsoft so that they can provide the best software so that developers can provide the best experiences.

    Performance is a very real problem both in pure rendering capability and input responsiveness. Both are absolutely vital to great end user experiences. Just take a look at scrolling experiences in WPF or Silverlight.

    I don't mean to be too critical here but an iPhone 3GS can out render WPF and Silverlight on the desktop in both rendering fps and input responsiveness without nearly as much visible issues with UI virtualization. WPF and Silverlight have a bunch of issues when it comes to UI virtualization, performance and responsiveness.

    We are hard because we want to see it improve and become the technology it deserves to be so that end users can benefit from modern rich and responsive experiences.

  3. Dennis Heijsays:
    Yes, the performance of WPF is poor at best.

    Animating a form with ordinary textblocks and textboxes will stutter on anything less than a monster machine. Should you ever try doing any sort of visualization containing a few thousand primitives you better not animate anything unless you spend quite some time resorting to old school 8-bit type of tile scrolling and the like.

    Using the lowest level primitives to render a line polygon will peg the CPU with not very many vertices. Using the DrawPolyLine offers no perf benefit over DrawLine.

    List scrolling is a topic in and of it self, however there at least exists workarounds for those.

    All this said, I love the API and the posibilities it allows for, and I wouldn't want to go back to GDI and WinForms. Now, why couldn't the backend be changed to use Direct2D if that is available?
  4. Raymond C.says:
    Hi Folks,

    Quoting the original article: "I will say my customers that just build LOB, they generally don’t have many complaints and are just happy with the developer productivity. It’s the folks that want to build experiences (ie, consumer apps or kiosk apps) that are in pain." The author did not criticize or praise the technology, just say some truths about the WPF rendering system and it's performance and fesability for different consumer targets. The "insights", quite good for someone not working at MS! :-)
  5. Chris Nahrsays:
    Great post by Jeremiah Morrill. Like most WPF developers I'm annoyed by the sluggish performance but I thought the reason was its complex internal rigging before anything gets rendered in the first place. That the rendering process itself is such a major culprit was very surprising to me.

    I can accept some performance degradation due to WPF's elegant and powerful layout system -- it's what makes WPF so enjoyable and productive from a developer viewpoint, after all. But if low-level rendering issues really have a significant impact on real-world performance, the WPF team ought to make fixing them their top priority.
  6. Jeremiah Morrillsays:
    Olivier,

    Very good points! I believe we are actually in agreement on a few key points:

    >>Kind of bitterness, just a feeling of course.

    I think it can be described as a bitterness, but my perspective is a yearning for things to become better. Being entirely happy with the state of things doesn't help move things forward. Praise the good things, critique for improvement.

    >>I think performances have always been "the" problem in our profession !

    Absolutely! Many of my customers come to me for performance type solutions. We always want to cram as much _stuff_ in our applications to add value for the end user and performance is key to enabling that.

    >>Of course, WPF and SL seems to be not well optimized when it comes to deal with intensive graphic activity. It is a bit a shame since these environments are dedicated to create "UX oritented" application."

    I could not agree more! In fact, that's almost the exact sentance I used in an email about this recently. These graphically intensive applications are becoming more mainstream. Surface applications are a very good example of these immersive applications that do need to be graphically intensive. It's not hard to imagine that developers would want similarly intensive applications running on desktops.

    >>but "look how bad is WPF !", bitterness and treason, and then it fails on the technical argument part.

    I didn't mean to offend you or anyone by posting this. I also realized that not everyone is well versed in Direct3D or the ins and outs of GPU programming, so it was very difficult for me to put everything in laymans. I did want to point out where I see inefficiencies, but also did not want to write a thousand page scientific paper on the subject either. I did my best to provide information how one could run their own tests to verify my claims, and hopefully engage in an objective discussion if their results did not match mine.

    I believe the only place where we really disagree is here:

    >>The real question is "are the performances of WPF and SL good enough for the vast majority of the applications ?". I think the answer is Yes.

    "Good enough" is very subjective and it's also a level quality that I try to _never_ deliver to a customer. Though it's only my opinion, we should all pride ourselves on being able to give end users what we feel is "the best". That of course, always needs to be taken into context of goals, time and money. But given enough of those three, there still is a hard limit of what the UX platforms can deliver.

    BTW, I use Windows because I believe it to be the best, not because I feel its "good enough" :)

    Thanks again for reviewing my article!

    -Jer
  7. Bensays:
    Pete,

    I commented on Jeremiah's article but I thought I'd continue here.

    I'm working on a touch screen application for an embedded medical device. We're using .Net 4 on WES7. We think the UI provides a massive user experience improvement over our competitors and it's largely thanks to what your hard work on WPF enables us to do. The visual results achievable by a very small team are incredible.

    But... we just can't achieve the ultra responsive "feel" of an iPad app with our WPF UI, and this is basically marketing's #1 requirement. The WPF animation system just doesn't provide smooth animations, especially when translating large amounts of content through RenderTransforms, and especially when running on lower end hardware. And anytime you run continuous animations--which help make our app feel "alive," as recommended in the Microsoft Surface UX guidelines--you get relatively high CPU loading.

    Bottom line, my development team sold management on $80 WES7 licenses and some beefier, more power hungry X86 hardware because of the amazing capabilities and productivity that WPF offers, as well as the promised hardware acceleration, but now we're having to scale back our UX somewhat (cut down on the "fluid" UI) to make things more responsive. Honestly, it's getting to the point where we could have achieved similar results with Qt on Linux with cheaper ARM-based hardware, and it's probably only a matter of time before one of our bean counters figures this out.

    I agree with other posters that WPF provides more than good enough performance for LOB applications with traditional UI's, but it's capable of so much more than that. We just need improved performance to enable it. Let us fly. Or, at least give us easy Direct2D interop without airspace issues, ideally with a nice managed wrapper. That would get me out of my real-time charting bind :)

    Thanks for all your hard work,
    Ben

Comment on this Post

Remember me