Im writing an application for embedded device that can display 3d coverflow like ui.
Requirements
1. High performance (60fps, preferably GPU accelerated)
2. Run in browser.
3. Supported in linux(android if possible).
Im not familiar with web/browser technology, but im familiar with .net/wpf and little silverlight. Ive tested multiple silverlight coverflow and perspective correct transformation is a bit laggy. the best implementation imho can be seen here http://coverflow.darickcarpenter.net/. it has virtualization, perspective correct. performance could be improve by disabling transparency altogether. im not sure if its gpu accelerated. im not sure how much performance can be squeeze from silverlight.
What platform/technology has the best 3d rendering performance in browser?
Edit. I just found a guy implement 2 similar coverflow in silverlight and javascript(webkit). Performance wise, javascript is extremely fluid. I thought since silverlight is created by microsoft, running silverlight in ie provides best performance. I thought silverlight 5 have gpu rendering support. Any opinion?
I would choice WebGL/HTML5 for near future browser technologies with attention to high performance.. It's also usable for most mobile devices with android right now..
So you might start with this pretty implementation in WebGL (also contains code) http://www.coconnut.com/blog/2012/07/25/html5-javascript-webgl-ejemplo-de-galeria-con-menu-tipo-coverflow/ .
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 have an application that has some controls that use GDI+, mostly simple stuff with low graphics rendering requirements although I do have a couple of animated GDI+ windows that are borederline usable because of poor GDI+ performance.
Moving forward I would like to start using WPF (for performance and to learn WPF) but I also like to keep code compatible with Mono. As such I was wondering if I should or could develop using Silverlight (Moonlight in Mono). That way I get some WPF skills (I undertand silverlight is a subset of WPF?) and good performance.
Silverlight/Moonlight is a far better choice for any type of graphics and animations. GDI+ is old, and the Mono implementation exists mainly to support Winforms, which means it's not going to get any better. OTOH, while on the surface both use Cairo (as the previous poster mentions), that's like saying both render text - yes they do, but that's pretty much where the comparison stops. Moonlight is targeted for fast rendering, you get vectorial animations, you get hardware support whenever possible for graphics chips, because it really needs to be fast, it needs to support video with realtime render effects, 2D and 3D, etc. It might be that it's not yet up to par with the latest Silverlight version, but that doesn't mean it doesn't do what you need already. If you have the choice, go with new technology that's being actively worked on, not old stale tech.
Silverlight is indeed a subset of WPF allthough there are quite some details that work differently. Moonlight is currently compatible to Silverlight 2.0 but Microsoft is at 4.0 now with Silverlight. Moonlight will probably be always far behind Silverlight and even farer behind WPF. But if you can live with that, Moonlight might be a good choice. However if you will probably not see any perfomance improvements because Mono is using Cairo for rendering both GDI+ and Moonlight.
I also expect Mono's GDI+ implementation to be much more mature that the low level rendering APIs of Moonlight.
C# code that uses GDI+ instructions provided by System.Drawing currently are not compatible on Linux using Mono.
A null reference or invalid value was found [GDI+ status: InvalidParameter]
AFAIK no one was able to solve this error.
I’m working on creating a full-screen 3-D app (based on Johnny Lee's Wii head tracking app) with some augmented reality features, and it seems that WPF is too slow to render even the simple models I’m using at a reasonable frame rate. I think the problem is that I need to change both the view and projection of the camera on just about every frame, because of the nature of the app (it uses a web cam to track your face, and uses that data to move the camera around and change its perspective).
I've spent a lot of time trying to narrow down the problem, and it's definitely related to the graphics, and not the speed of the head-tracking API that I'm using. Also, I recreated the app in XNA, and it seems to work fine there (28 FPS versus 9 in WPF). Finally, when I remove the "walls" or make the window much smaller (say, 800 x 600), WPF's performance greatly improves, which makes me think that the bottleneck is the graphics calculations.
As a result, I need to either find a new graphics back-end to work with, or find a way to make WPF much faster for this app. I’m mostly looking at DirectX and XNA, and possibly OpenGL. Any recommendations on which of these APIs would be best to use for this app in .NET? Or alternatively, any idea what I'm doing wrong in WPF that's slowing things down?
I've not done enough with 3D in WPF to be able to say what could be causing the slowness, but I did notice that it's model datastructure isn't very efficient. While this might not be the cause it could be symptomatic of general slowness to the whole pipeline.
One thing that does spring to mind is that WPF is rendering the scene in software rather than using the hardware acceleration on the graphics card. The fact that you get better performance (though you don't say how much better) with a smaller window.
If you remove any textures from your model do you get better performance too?
I don't think it really matters whether you go for Direct3D or OpenGL - virtually all modern cards support them equally well. XNA is the obvious choice if you're sticking with .NET as it's integrated into Visual Studio - even the Express edition.
I would check out SlimDX, a much thinner DirectX wrapper than XNA or WPF
The problem with changing the projection on every frame is that API's like XNA/WPF werent designed with this in mind, so were optimized to have projection set once in the initialization phase, then not again.
I would suggest a hybrid choice here: use WPF for what its good at (Windows UI, composition, etc) and use XNA to render the 3D. There are samples out there that demonstrates combining XNA with WinForms. It should be possible to do the same "trick" to render XNA onto surfaces in WPF.
Update: there are supposedly issues with using XNA directly with WPF. This thread indicates that using XNA with WinForms and then hosting the WinForms control in WPF is a workaround to these issues. I've not tested this myself though (yet).
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.