We tried cached composition but it didn't make any difference - we probably couldn't use it anyway since we definitely want sub-pixel rendering for text. Can't say much about WriteableBitmap but I guess the same restrictions apply and applying effects would be difficult.
I believe that the main reason for our performance issues is the complexity of the XAML based template for our topics (the elements on the map) and the use of a RichtextBox in it. In the current version a (very simple) topic consists out of 63 visual elements. Most of these are just empty panels, place-holders for images, icons etc. The biggest part of it is the RichtextBox which has 12 visual elements. In the new re-written version the same topic has only 3 elements (main shape, text renderer and the connection renderer). The main shape is a canvas where we can place the images or other elements on the topics, if they exist. The shape itself is drawn directly via OnRender. For a medium sized map this means a reduction from around 32.000 elements to 2.000. Surprisingly the performance of the application with 32.000 vs. 2.000 elements is not much different but the initial creation of the elements is a lot faster. The most expensive control seems to be the RichtextBox. Obviously the RichtextBox is unusable for these scenarios. It is just a shame that we even have to go that deep to write our own rich-text rendering and measuring. Even though it is not that difficult (famous last words), it isn't trivial either - especially if you want to properly support right-to-left languages. It definitely has a massive impact on our time plan and resources. (The fact that a lot of our customers are angry because we don't yet support tables and bullet points is another thing I wish we wouldn't have to worry about.) Our Mac team is constantly flabbergasted that we have to spend so much time and energy on things they take for granted. It is a shame that we cannot support vector graphic images (on the Mac we actually use PDF(!) files as icons in the UI!) or enable exporting the Map to PDF... or provide a good installation/update experience... or a good spell checker ... or have a extensible print/print preview dialog... or a video player control... or a usable font picker/color picker... or a media library... We have or are investing in most of these areas to get around the limitations but it takes a lot of work and determination. Some of these things are of course not WPF specific but apply to the Windows platform in general. Personally I feel like C# is so much better than Objective-C but the framework on the Mac seems so much better at providing features that work and matter.... Then there is animation. I guess I just need to learn a lot more about it but it is extremely disheartening to see for example prezi.com (implemented in flash) happily and smoothly animate a giant canvas on my 30" screen and see my own extremely simplistic WPF application choke and stutter at the same resolution. I guess the grass seems always greener on the other side ... :) cheers, Patrick On Thu, Oct 28, 2010 at 1:19 PM, <[email protected]> wrote: > Send ozwpf mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ozwpf digest..." > > > Today's Topics: > > 1. RE: Evernote ditches WPF (Paul Stovell) > 2. Re: Evernote ditches WPF (Winston Pang) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 27 Oct 2010 18:30:51 -0700 > From: Paul Stovell <[email protected]> > Subject: RE: Evernote ditches WPF > To: ozWPF <[email protected]> > Message-ID: > > <c5bdf7db44480447ba81207d4a4d868c029db94...@sg1rd3xvs061.red003.local> > Content-Type: text/plain; charset="us-ascii" > > Hi Patrick, > > 3.5 SP 1 and 4.0 seem to have eliminated most if not all of my gripes. > However, I'd say the kinds of apps I build are very different to yours - > mine tend to just involve lots of pages and list boxes :) > > For the typical data/process-centric application (think > http://www.istartedsomething.com/20080109/frog-design-wpf-sexy-enterprise-software/or > the kinds of apps built by > http://lab49.com/), it's hard to imagine switching back to GDI+ for these. > For the most part, this isn't because of graphics - it's actually because I > find the data binding, layout and templating features make it easier to > surface the information I want quickly. With Windows Forms (or C++/GDI+) I'd > spend days just trying to show a list that isn't a DataGrid :) As long as > the performance hit of WPF doesn't become a bottleneck, it's a great > platform. > > For the kinds of apps you're building, it's hard to see the compelling side > of WPF. Perhaps you'll get benefits from the non-core parts of the app by > using data binding/layouts/etc., but for your core mind map control, I'd > probably agree with you that it's not a good fit. I'm sure if you dedicated > enough time to it you could make it work, but that would go for C++ with > OpenGL or GDI+ too. There's something beautifully simple about GDI+'s > immediate mode rendering that makes it great for scenarios like that. > Without having much experience in the high-performance rendering world it's > hard to know for sure. > > I also think ISV's are more likely to be worried about things that we'd > generally brush over. For example, I can confirm that the RichTextBox is > slow - but until it's completely unusable, we can usually tell users to > "live with it" if there's no easy alternative - the joys of a captive > audience. As an ISV in a competitive market you don't have that luxury, so > you're probably more likely to spend time trying to solve this. But maybe > you'd experience the same problems using MFC controls? I hope Evernote > release more information on their experiences going the other way. > > Putting it this way, if we compare the rendering performance of DirectX, > OpenGL, GDI+ (in some scenarios) and WPF controls, WPF would probably come > out on the bottom - and for most of us, that's not a problem, because our > apps aren't so sensitive or don't do much in the way of complicated > rendering. But if your application is sensitive to this, and you go with the > slowest option, it's not surprising that you might have problems. To be > fair, back in 2007 everyone assumed WPF would be closer to DirectX/OpenGL > than GDI. > > Just out of curiosity, how do you find the performance of OnRender compared > to say WriteableBitmap? And does cached composition help at all? > > Paul > > > From: [email protected] [mailto:[email protected]] > On Behalf Of Patrick Klug > Sent: Thursday, 28 October 2010 10:54 AM > To: [email protected] > Subject: Evernote ditches WPF > > 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<http://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? > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://prdlxvm0001.codify.net/pipermail/ozwpf/attachments/20101027/118c5d99/attachment-0001.html > > ------------------------------ > > Message: 2 > Date: Thu, 28 Oct 2010 13:00:50 +1100 > From: Winston Pang <[email protected]> > Subject: Re: Evernote ditches WPF > To: ozWPF <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > 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 > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://prdlxvm0001.codify.net/pipermail/ozwpf/attachments/20101028/0db059db/attachment.html > > ------------------------------ > > _______________________________________________ > ozwpf mailing list > [email protected] > http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf > > > End of ozwpf Digest, Vol 9, Issue 20 > ************************************ >
_______________________________________________ ozwpf mailing list [email protected] http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf
