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).
Related
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/ .
I know this may be a bit early, but I've just started a new game in silverlight, and thought it would be neat to start it in Silverlight 5. The only problem is, I can not find -anything- online about drawing 2D. The very limited info out there is only for 3D. Does anyone have any links to examples, tutorials, or even just documentation that would help me with this? Would perhaps waiting a few weeks/months do me any good with google results?
Or am I totally wrong in my thinking, is silverlight 5 actually no more efficient at drawing 2D than Version 4? (or the slight benefit is not worth the complexity of drawing polygons in 3D space, and painting sprites on them)
If you want SpriteBatch in Silverlight 3 (or newer), use ExEn. It uses an elegant hack to get hardware accelerated immediate-mode sprite rendering using Silverlight's retained-mode graphics system.
(You could also use the retained-mode graphics system directly - but that is kind of painful for game development.)
If you want SpriteBatch in Silverlight 5, try the Silverlight Toolkit, which adds an implementation of XNA's SpriteBatch (and other handy things) on top of the subset of the XNA API that Silverlight 5 provides.
Check out this question and answer for a few tips on using it.
The major advantage of using the XNA stuff in Silverlight 5 is performance. It's hardware accelerated and it's immediate-mode rather than retained-mode. Ideal for game development. (And it can handle 3D.)
The two disadvantages are that there's a smaller install base of Silverlight 5, and not everyone has a video card capable of providing the hardware acceleration that its 3D stuff requires (whereas the retained-mode stuff can at least fall-back to software rendering).
By the way: Drawing in 2D using the 3D API is really pretty simple: Just set up an orthographic matrix, disable Z-buffering, and don't worry about the Z-coordinate.
(Disclaimer: I wrote ExEn, and I'm yet to actually try the Silverlight Toolkit for myself.)
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 am beginning to heavily invest in WPF and was wondering what those more knowledgeable than myself thought as to the wisdom of this decision. Is WPF the way forward?
Yes, it is the way forward.
WPF and using XAML for interfaces has completely revolutionised the way in which we develop said interfaces for our customers. The possibilities are endless, the learning curve is large, but with merit.
We can now do things in XAML that we couldn't dream of doing 3 years ago with WinForms - or things that take a few lines of code and an hour of logic that would have previously taken a full week of logic and four class files.
It's definitely the way forward for MS development, however there will always be people using WinForms.
They even developed VS2010 with WPF, that must give it something, right? ;)
Microsoft itself has begun developing its enterprise applications in WPF. They are invested in keeping it going for themselves, no reason to believe that the rug will just get pulled. Also, WPF has the Silverlight subset, which doesn't seem to be losing steam.
XAML is a nice, declarative method of setting up your interfaces with a lot of slick value conversion done for you and the opportunity to add more behind the scenes. It's possible to separate it from WPF, however (although they generally go hand in hand).
I understand that .Net 4 has made some progress toward using the XAML declarative language in Workflow Foundation and in Windows Communication Foundation, which will be interesting, given that those two are already fairly heavily declarative XML driven.
So, XAML is definitely the way forward for MS, especially given that at the core it's nothing more than a way to construct an object graph - any object graph.
WPF is also going to take some strides - for instance, inclusion of the much missed DataGrid (there are excellent commercial alternatives already), and more complex pixel shaders which should push more work to the hardware and increase rendering and startup speed of WPF apps.
As to whether WPF is THE future? Yes, for people who are tied to Windows, who value stylus input and handwriting recognition and who can find space in their development budgets for attractive UI development.
Against Flash, Flex, DHTML in general? I don't know. I'm inclined to think not - most applications don't need the full power of fat client development and don't care that much about pixel shaders et al, happily trading it against the accessibility of web.
Silverlight and XAML are not seamlessly cross compatible, and WPF doesn't transfer automatically to the web. (Yet?) Nevertheless I took the gamble on skilling up, and have found it to be time well spent. If nothing else, it's fantastic for prototyping.
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.