We are considering switching from Adobe Flex to Silverlight because Flex is just too slow.
I'm interested not in graphical performance, but computational performance and the speed at which it executes code.
Does anyone have any anecdotes to share about their experience of Silverlight performance?
Unlike Flex, Silverlight is multi-threaded. Which if used properly gives you the ability to write highly performant apps. There are many articles and blog posts on this. Here's a sample...
http://www.silverlighthack.com/post/2008/09/07/Silverlight-MultiThreading-with-a-Computational-Process-(Counting-Primes).aspx
tobinharris posted test results of calculating 1,000,000 primes. Silverlight was the clear victor for performance.
I've found that Silverlight handles the computational performance quite well. I've been disapointed by some of the graphical performance. Since that isn't you problem, I'd suggest some test with a few complex processes. I haven't used Flex, so I don't have a my own test for the difference.
Silverlight allows for multi-threading which is great for processing large amounts of data (and as an aside makes the UI seem faster/more responsive to a user)
Silverlight 2 apps written in >Net should run just as fast as .Net apps. There are compiled locally and run "natively" in a managed environment so the performance should be the same as any .Net app which I have found to be pretty darn good or at least programmer-talent-contrained and not toolset-constrained.
My big concern would be that you are running on the client and you will have little ability to know what the speed will be client to client. The min requirements for SL are pretty meager
Also, lots-o-processing typically means lots-o-data so you will want to look into using Isolated Storage (another neat SL feature) and compressing any WCF calls (use IIS7 and turn on dynamic compression)
Not sure about how flex does work on the client side.
What I like frokm Silverlight is that a real OOP language (C#) and all is compiled, about computation power, Scott Guthrie published a link to a chess game (same algorithm / implementation approach but javascript vs. silverlight), interesting how SL behave.
In the app I have developed I haven't had any issue on performance (some samples are managing more than 70 tables and relations) working with LINQ to XML... jejej where I have found some samples is fighting against some buggy controls on SL (combo and datagrid).
HTH
Braulio
To add on to Caryden's answer, Microsoft is working on a multithreading library that makes it very easy to write multithreaded code (Will be part of .Net 4.0). This library will most likely make it into the Silverlight libraries in a future version.
Reading this site and the comments relating to the various posts might help you:
http://www.shinedraw.com/flash-vs-silverlight-gallery/
Reality is Silverlight currently has an inferior rasteriser with some issues (outlined on the site linked above). But, as it has been mentioned here, you do get other benefits that can assist the rendering process such as multi-threading. Recently we ran into a lot of problems with rasterising of input text causing our Flash (for the sake of this conversation Flex is Flash) presentations to hiccup, there is no really good solution for this in Flash at the moment.
I would also suggest you will mostly get web and systems programmers giving their opinions here, rather than computer graphics programmers.
Related
I have been working for some time on a library which performs numeric calculations. It is written in pure native C++, and until now I have been using simple console applications to test its functionality.
The time has come to build a GUI on top of the library - to better display tables of results and also to render them in graphical form.
I was always planning to use WPF to implement the UI and have spent some time researching it, but I am now having second thoughts. My worries about WPF are:
Is it worth coupling my program to the .NET framework just for the sake of the user interface? .NET and WPF seem to add overhead in many forms, including:
Program complexity
Using .NET implies using a second language - and thus writing lots of messy interop code.
Runtime performance
In particular, WPF applications seem very slow to start up.
Deployment
Is .NET framework installation quick and easy? Does it require rebooting the machine?
Rendering quality
This has improved in WPF 4, but display of standard elements still seems poor in some areas.
Concern over whether performance and quality will improve in the future
Is it true that WPF is being de-emphasized within Microsoft (in favour of Silverlight)?
My worries are compounded by news of people moving away from WPF having faced similar issues - the most recent and highest-profile being Evernote.
Would you recommend I stick with my original plan and use WPF?
If so, what do you think about the above issues?
If not, what alternative libraries could I use to create a high-quality Windows GUI?
Edit:
Thanks to Reed Copsey for addressing my individual points. The reply suggests that most of the issues I have with WPF can be worked around.
It seems that using WPF will involve more work than would be ideal - including writing interop code and making tweaks to ensure good performance and high quality. Do people generally agree with the statement that, in spite of this, the best way to produce a top-quality UI is with WPF - rather than with any other framework?
I'll try to address these in order. Spoiler: In my opinion, for the most part, the answer is yes.
Is it worth coupling my program to the .NET framework just for the sake of the user interface?
This depends on the interface requirements. Do you users need a good, solid, modern UI? If so, you'll want to use the right tool to deliver that requirement.
.NET and WPF seem to add overhead in many forms, including:
Program complexity
Using .NET implies using a second language - and thus writing lots of messy interop code.
You can use GDI+ via C++/CLI, and handle everything in one language. That being said, part of the reason people use other languages for this is productivity - it's actually very, very fast compared to making a GUI in C++. The interop code via C++/CLI is not very messy at all, at least not if your routines are class-based.
Runtime performance
- In particular, WPF applications seem very slow to start up.
This can be an issue, to some extent. You can do a lot to mitigate it, however - but this will probably always be a bit slower to start than a lean, native codebase since it has to spin up the CLR + libraries.
Deployment
- Is .NET framework installation quick and easy? Does it require rebooting the machine?
Yes on both counts, typically. That being said, most people already have the framework installed (esp. if you target .NET 3.5, but 4.0 is coming along nicely), so it's a non-issue. I always see this as a one-time thing, though - I'd much rather trade a nice user experience for a bit of deployment time, especially when it's a relatively pain-free deployment (.NET's very easy to install, just large and a bit time consuming).
Rendering quality
- This has improved in WPF 4, but display of standard elements still seems poor in some areas.
I'd strongly disagree here. WPF is (esp. in v4), the premier platform for quality user interfaces. It's tough to beat the rendering quality options in WPF -
Concern over whether performance and quality will improve in the future
- Is it true that WPF is being de-emphasized within Microsoft (in favour of Silverlight)?
No. There was even a good talk at the PDC of the future of WPF. Silverlight gets a lot more press, but that's mainly because it's not nearly as mature of technology, so it's changing more quickly. WPF is still their top of the line UI experience, and still getting new features added. It's also the suggested platform for interop with native code - while it's possible in SL using COM, it's not pleasant like in WPF.
Performance, threading issues, and airspace issues seem to be the future improvements in mind, according to the PDC talk. For details, watch "The Future of WPF."
I'm mainly asking this to professionals who know the playing field of professional developing. Is it worth it to learn and develop skills in Silverlight?
I know that penetration for Silverlight is obviously low in comparison to Flash but Silverlight seems lighter and a more cutting edge technology.
What are some of the benefits Silverlight has over Flash?
Is there a lot of work for Silverlight developers (of course combining them with ASP.net)?
Thank you very much for all the responses. :)
Edit: I program mainly in C# so there will be an obvious plus side to using it.
Also, how reliable are these results: BubbleMark
It's a huge topic and you can read articles all day on Flash-vs-Silverlight-vs-AJAX.
I use Silverlight and was completely over the moon when it was released due to the ability to employ the CLR in browser based applications. Javascript/DHTML development drives me nuts and for me Silverlight was my way to escape its clutches. As far as Flash goes my very brief foray into it found ActionScript to be more painful than Javascript but that was years ago and things have undoubtedly improved since then.
Basically if you're using .Net for your back end then it makes perfect sense to use Silverlight for the front end. It means you only have one development environment and language to deal with and where appropriate you can reuse a lot of your back end code on the client.
In practice it's not quite that easy and my experience has been that there is a lot of resistance in user land towards Silverlight. The main bone of contention is generally that the cross browser and operating system support is not good enough. Users that employ Opera or use Linux or PowerPC Macs can't use Silverlight (Moonlight isn't there yet). Those users are generally vocal ones.
If you know all your users will be on IE/Firefox on Windows/Mac Intels or you have a compelling application that users will change their set ups for then Silverlight is almost certainly your best option. If you have an application that you want to hit a wide range or disparate users you may need to weigh up the options a bit more.
The fact that Microsoft has thrown their weight behind Silverlight as the Web Application Framework of choice gives it a pretty decent chance of becoming widely used (though certainly no guarantee).
To position yourself in the most versatile way, though, you might want to consider first learning about the capabilities and limitations of both systems and then learning how to implement with both.
There will probably be many projects done with Flash, and many done with Silverlight. If you can program to either, you will be in a good position. If you are able to provide skillful assistance in deciding which one is best for a given project, you will be in a great position.
I tried it and did not like it. I didn't like the split development environment, xaml, or the limited install base and platforms it runs on. The IDE and platform itself still has a ways to go before I would consider it for use in a production environment.
I'm getting ready to develop my first Silverlight app. It is going to be primarily used by my church for data input but also will need to generate at least one report, ideally in Excel but XML/XSLT is not outside the realm...
It will be Internet facing and will talk to a SQL Server 2008 db for which I will be creating a web service hosted at the ISP (db is also hosted at the ISP). The clients will be a mix of Windows and Mac.
My question specifically relates to the interface architecture. I know MVVM is big for this right now and I'm comfortable with that. I want to get this up fairly quickly (ie- next 3-4 weeks). I've also seen mention of Prism (Composite Application Guidance) and Caliburn. What are anyone's thoughts on these two? The initial version of the app is not going to be huge so I don't imagine it would be overly difficult to refactor a framework into it at a later date.
You are right, if it's your first development on SL, adding the complexity of MVVM won't help you much.
I think a good approach could be to go for something simple (e.g.: the good old Document/View could be just a good start http://msdn.microsoft.com/en-us/library/4x1xy43a(VS.80).aspx, or just breaking in standard layers, UI / BS / DL).
After that development you will have learnt a lot of good stuff, and then you will be able to throw your app and start new bigger challenges using more advanced architectures (about MVVM, a very good web cast: http://blog.lab49.com/archives/2650 it's WPF based most of the concepts can be ported to SL).
Good luck and enjoy for SL development.
Cheers
Braulio
Start with something you are very comfortable with especially if you need to get this up quickly. Follow good coding standards and should not be a problem to refactor later into other frameworks if you get a bigger team.
This is a useful pdf.
I haven't read it in detail yet myself, but this article looks rather useful:
RIA Architecture with Silverlight in mind
How is Silverlight going to change the internet in the next 10 years?
Is this going to be a scene changer or just another blip?
People often underestimate Microsoft. I don't know if it's going to change the Internet, but Silverlight will probably become pretty widely used, especially in web-based business applications that require rich interfaces. Flash is good, but being able to develop rich web interfaces with .NET and WPF is much nicer, particularly in that realm.
It will be another blip. It's not seriously cross-platform, unlike Flash or any of its other competition, and no one seems particularly interested in it. It might be neat and shiny but I haven't seen any real reason to move past playing around with it.
Put another way, it's a cool toy but not much else.
Until Silverlight has respectable implementations in other operating systems (read: OS X and Linux) and it can differentiate itself from Flash considerably, it's never going to grab a significant percentage of the rich content web app market, IMO.
I personally think Silverlight will be popular, its got a good "feel" about it IMO as a developer.
The cross-platform issue will be solved soon, as Mono continues to grow fast.
But I think it will be a very long time before anything knocks Flash/Flex off its perch on the top of RIA development platforms.
Silverlight allows the developer to offload some processing to a CLR on the client, using the native language such as C#, provide rich interfaces that are not restricted to HTML/CSS/DOM differences between browsers, and potentially reduce the need for scripting in javascript.
Although I might seem antagonistic here, I really, full heartedly don't like Silverlight, and I don't like Flash either.
They don't bring anything to the table anymore, now that browser are truly fast at rendering and processing. You can do most of the same things with pure Javascript and HTML/CSS. And what you can't do you will be able to do with HTML 5.0. What we need are not more proprietary frameworks, but better tools for what what we already have.
So my guess is 10 years from now, Silverlight and Flash won't be more than wikipedia articles.
I feel that while you can do most of what you need with Javascript and CSS, Silverlight programming feels much more fluid and fast to me. This is especially true when it comes to easily building a rich design with loads of animations. It is very easy for a team of designers and developers to collaborate on Silverlight and WPF projects, and that efficiency is important. Visual Studio being a fantastic IDE has kept many developers on the Microsoft ranch. The Expression suite feels like the next big advancement in allowing your IDE to do a lot of your work for you.
Deep Zoom is another big winner for Silverlight - check out the Silverlight implementation of the Hard Rock Memorabilia collection. Now look at the Flash implementation of SF Moma's art collection.
Don't knock Silverlight until you try it. I am no Microsoft fanboy, but it is very easy to use. People who have never developed using Microsoft technologies don't know the meaning of a good IDE.
I mostly develop with PHP, and I use Aptana for development. VS200x is lightyears ahead of any other IDE in just about everything.
The only real thing standing in the way of Silverlight becoming more widely used is better cross platform support; which would be pretty amazing thing I don't see happening at all. If Microsoft could loosen the reins up a bit, it would do wonders for it. Then again, Microsoft has gotten got at getting certain really good tools out there for free: The Express VS tools, the Dreamspark suite, etc.
One area that Silverlight will catch on is business applications. As architecture models shift into the service oriented realm there will be many companies looking to port their old client/server apps. Silverlight enables them to maintain the rich UI of the forms application while providing the messaging capabilities necessary to talk to the services. Also,t he deployment is wider than what they would get with strictly WPF and xbapps. Flash doesnt really compete in this area and a straight asp.net or other web technology front end, while getting nicer with Ajax and all that fun stuff, wouldnt support the richness you can get out of silverlight.
My company is just starting to look at using WPF for migrating all of our 10 year old business applications. These applications will most of the time be running on computers that have limited/old hardware. We are now a little worried that the hardware might be too limited for using WPF.
We have installed Family.Show (http://www.vertigo.com/familyshow.aspx) on an basic older computer and that seems to run ok. But we would like know what your experiences with WPF on older hardware is? Anyone out there willing to share some experiences with us?
I would add several things:
The first is, as Stu said, it really depends on what you are doing. In particular, we have found a noticeable difference between WPF 2D and WPF 3D. If you are doing any WPF 3D stuff at all, your performance is highly dependent on the quality of the video card (see the Graphic Rendering Tiers link already mentioned). In particular, we released a WPF 3D feature in April of this year, and it really only worked smoothly on Tier 2 hardware.
Second, I would point you to Jossef Goldberg's blog. It has a wealth of information on WPF performance related items.
Third, I would grab and utilize the WPFPerf tools. They were recently updated actually. Jossef's blog post will point you in the right direction there as well.
Fourth, take advantage of virtualization wherever you can.
Finally, I would recommend monitoring performance all the way through the development life cycle. I think the story goes that originally the Blend team did not evaluate performance (for their first release) till closer to the end, and it made solving the problem much more difficult.
Update: There is another StackOverflow post on this subject. Just wanted to point others to it.
WPF apps will generally run no slower than their equivalents using other technologies. In other words, performance depends on what you're doing. If you have a basic app with some simple data entry controls and a grid or two then it'll be a lot less demanding than an app that has animated custom controls with overlaid video, etc.
You should also bear in mind that you must have at least XP SP2 to install WPF, which sets a reasonable hardware baseline anyway.
In summary you should have no problems running a WPF app on older hardware as long as you are sensible with the frills. Given WPF's templated controls it's also fairly trivial to test for a basic level of client performance at runtime (see Graphics Rendering Tiers) and only enable more advanced features on suitable hardware.