Hi Patrick,
Like you, sometimes I find WPF a pain in the ass, but it's a trade off in both ways, sometimes it makes it so easy to do something, but then the compromise is performance. Having said that, I still think there's a long way to go before new WPF developers can come along to the platform, without investing months in searching online for work arounds to squeeze performance, or for hacks to achieve custom chromes, or smoother animations. I'm currently working on a twitter client with two other friends ( http://www.metrotwit.com), and we had the exact same issues as you regarding the rich textbox, being a memory hog, and also not performant, it's such a pitty, it does give a lot of features to the developer, but with power we lose performance. Further to that, I've also worked on a few other WPF apps at work, one of them was similar to what you've had to do with drawing, it was related to rendering out AutoCAD floor plans, and adding additional things to it, and we ended up with WPF, but If i was to choose again, I probably wouldn't have used it, it consumes way too much memory, and a lot of time, we were just thinking of ways to implement clever techniques to lazy load a lot of things and defining a time when we can ditch things, it was very ugly to say the least. I find that, Microsoft, still hasn't got up to the stage of supporting their concept of Designer + Developer workflow, it doesn't work at this stage. You have all these MS guys or vendors doing spinning presentations of dragging stuff in Expesssion Blend, databinding it up to some dummy class, blah blah, and then palm it off to the developer, sure... that would work, until the developer populates the ListBox/DataGrid/other control, with a lot of data, then run it and realise the app is running dog slow, because the designer has some funky drop shadow effects or a complex data template, then get turned back by the developer to say, hey lets not use drop shadows, its killing it all. Poor designer, he spent a day on choosing what colour to use for the dropshadow. Then the designer needs to be buy a technical cap and put that on, so he understands why the bloody hell he can't have nice shadows or so much gradients. It doesn't make much sense to say the least. Not to mention I find that experienced WPF developers often seem to take these caveats and gotchas as is, "ok dropshadows are bad, what should we do? we'll just ditch them! or maybe we'll try to replicate it with a combination of borders and rectangles, and fill the XAML up with ugly hacks". Then you have people trying to make custom chrome apps, and realised that oh damn, my app covers the taskbar now, I'll just bind it to the system monitor height and width, and realise it's stuffed in multi-monitor scenarios. Sometimes I also find the WPF forums on MSDN useless, I obviously went there to post because google hasn't helped me, but what do some of those moderators do? They paste me a list of code project links, wow! Nice, like I couldn't google it myself? Aside from that, I do get some good replies from time to time, from some MVP's and other experienced devs, but some of those moderators aren't that great at helping out. I would say that, I still like WPF, it's opened a whole lot of different opportunities for making a variety of apps that use to be quite hard to develop, but I think there is a long way to go, before WPF ships with the ability out of the box to do a lot of things, without having to be so easily penalised in respect to performance. I know a million people on this mailing list is gonna tell me off one way or the other or call me a n00b because I could of done it this way or the other, but this is my experience so far of WPF. Cheers. --Winston On Thu, Oct 28, 2010 at 11:53 AM, Patrick Klug <[email protected]> wrote: > Seems like Evernote has ditched the WPF platform and rewritten their > complete client in C++ > > http://blog.evernote.com/2010/10/26/evernote-4-for-windows-is-here/ > > Reasons cited are the blurry fonts, slow startup times, large memory > footprint, and poor support for certain graphics cards. They were using 3.5 > - I wonder if .NET 4.0 would have solved these issues to a satisfying degree > or if C++ apps are simply the better choice for very popular client > applications. > > I have been working with a very small team on NovaMind, a mind mapping > application for Windows and Mac (www.novamind.com) and we have decided to > rewrite version 5 of our Windows client in WPF. The previous version was > GDI+/GDI/C# and the main reasons for moving to WPF was the ability to use > hardware accelerated graphics, animations and sub-pixel rendering for fonts. > The move to WPF has been... very challenging. > > At the moment we are finishing a major rewrite of the drawing layer. The > rich-text controls in WPF were just too slow and databinding and templating > seemed to be the slowest part of our application. - We couldn't actually > verify the exact cause for the performance issues in the application since > it doesn't seem to be possible to measure this ( > http://stackoverflow.com/questions/3305733/test-wpf-control-performance) > but experimental prototypes confirmed that the rich-text controls and the > XAML templating is slow. > > We had implemented control recycling and tried to cut down on element > counts and tried many other things but in the end it seemed that we had to > rewrite the drawing layer completely. > > In this rewrite (which took us more than two months) we had to implement > our own rich-text rendering and measuring control (something I always wanted > to avoid since it is quite cumbersome and complex). We also rewrote all our > map elements and are now drawing most of the elements on the canvas > ourselves by overriding OnRender. > > Performance seems more acceptable now. Opening a fairly normal sized mind > map with around 600 topics takes now around 4 seconds instead of the > completely ridiculous 40+ seconds before the rewrite. Of course in GDI+ this > was almost instantaneous. > > After we finish this performance rewrite we can finally start implementing > our presenter feature, which was the main reason why we moved to WPF in the > first place. > > Preliminary tests show that animating something smoothly and nicely is not > at all as easy as I would have expected and while I am confident that we can > create something truly outstanding in our market I know that it will be just > as challenging as it has been, ever since we have started with WPF (2007). > It seems that nothing we try to do 'just works' - I don't think that we use > a single standard control that we didn't have to tweak in some way to make > it more usable. > > What are you experiences? Have you or your team ever thought about ditching > WPF? Do you regret betting on WPF? > > _______________________________________________ > ozwpf mailing list > [email protected] > http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf > >
_______________________________________________ ozwpf mailing list [email protected] http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf
