About to embark a migration of a WPF application that uses ViewPort3D.
My 1st research shows this class is not supported on Phone 8.1. Am I correct?
And if so, what are my options for migration?
To my knowledge there isn't anything similar to ViewPort3D in Windows Phone. That leaves you with a couple of options:
Use PlaneProjection to re-create the 3D effects
This is very limited in what it can do relative to Viewport3D, but if your application is only using simple 3D effects, then it may suffice.
Use Windows Phone Direct3D
This gives you the full set of graphics capabilities, but requires low-level graphics programming with C++.
Related
I am working on a project and need to display a 3D scene (with animation) within my WPF application. It should be a relatively simple scene, but the hardware it will run on might be pretty constrained, so I am concerned about performance and efficiency.
I am evaluating whether to use WPF's Viewport3D, but am concerned that it might be using DirectX 9 on the backend. Ideally I wouldn't mind DirectX 11 or 12, though I suppose 10 would be acceptable. I hear DirectX 9 is less performant, though, so I'd like to avoid that.
Does anyone know what version of DirectX WPF's Viewport3D leverages under the hood?
Thanks.
For .NET Core there is an open issue around improving the 3D features of WPF, including upgrading to a newer version of DirectX, which also confirms the current implementation.
WPF still uses DX9 in both .NET Framework and .NET core.
Other references on that topic:
Source of D3DLoader.h (this line)
DirectX vs. WPF
Add DirectX 11 or higher support for Net Core WPF
Graphics Rendering Tiers
Recently I've stumbled over surface. It's incredible and so easy to develop small applications with surface. Surface is build upon WPF, so surface uses XAML. My idea is now to develop applications with surface. I've searched for some information about this topic. There is nothing about that. My question is now, why nobody uses the surface SDK with WPF to build cool applications. Are there any disadvantages?
I don't really understand your question. But here are some answers to what you may be asking:
Why aren't there more surface applications out there?
Most likely because of the price and the availability. It costs $15,000 for a developer unit and you have to be a business to even get to order it.
Why isn't the surface SDK used to build normal desktop apps
Because it doesn't make sense. The surface SDK contains Surface specific, and multi touch specific additions to the plain WPF stack so it is only useful for surface applications running on a real surface device (or simulator, but that isn't feasible for deployment)
Now if you are building a multi touch application for windows 7, there is a surface toolkit which is based upon the surface SDK. It has most of the nice multi touch enhancements but lacks the hard dependency on the surface hardware. It is very useful for general purpose multi touch development on .NET and is as far as I can tell also used quite much for this purpose.
Do you mean building Windows applications in WPF using the Surface toolkit? There is no reason not to do this. There is a 'good, better, best' model when developing multitouch apps, and if you want to create a true multitouch friendly application, then the Surface toolkit is a good way to go.
I have created an application using the surface toolkit but for normal wpf application.
You have just to have a multitouc tactil monitor.
and every thing will be fine.
It works :)
I am about to start development of a multi-touch application.
I need to decide between WPF and XNA.
Which would run faster ?
WPF already has libraries to support multi-touch via TUIO input.
Does anyone know a similar library or even just sample code to
drag/rotate/move objects in XNA ?
Thanks!
SW.
Touch is just another way of getting input from the user. Whether you route this input to an XNA app or WPF app depends more on what you want to do in the app.
XNA is a lower level api for doing 2D/3D on Windows, Xbox and Zune. WPF has only a higher level support for doing 3D and targets (currently) only Windows. So going with XNA vs WPF is imo more a decision of graphics requirements and platform support.
Since your app is graphic intense it could be more efficient to work at a lower level (read XNA or even SlimDX/DirectX). Reimer's XNA tutorials have a lot of great articles for starting out with XNA.
If you use XNA, you're going to be doing a lot of math to manually analyze the touch information - I'd check out WPF first (or perhaps you can host XNA visuals inside WPF and use WPF's touch input engine)
The Bespoke MultiTouch Framework supports multitouch and XNA together. Paul has a number of XNA samples already built to demonstrate the features you are looking for :-)
I'm starting a hobby project in which I would like to have a graphical, touchscreen interface for interacting with a kiosk-like device running on top of Windows XP Embedded. For development of a rich UI experience, I was considering using WPF. However, a number of demonstration videos that I have come across have used Silverlight, while I haven't seen a single WPF demonstration.
It was my understanding that Silverlight was targeted towards website developers, while WPF was more targeted towards desktop development.
So this question has two parts. Firstly, what is the recommended graphical subsystem for development of a rich UI experience on a kiosk-like device hosted on the Windows XP embedded platform? Secondly, if it is Silverlight, which version is suggested (1.0 or 2.0) and why?
It seems that WPF works fine on embedded. See here the second comment.
I think that your choice should be dependent on the type of kyosk you want to build. Some kyosks are just an open browser page. And then you have stuff like Microsoft Surface that can be used like an horizontal kyosk :-)
I would recommend also WPF, have done few kiosk apps using it.
also I would recommend http://fpscomponents.com/Product.aspx?id=8 as a virtual touch screen keyboard software component. it's done in WPF and very flexible and customizable.
User can define custom theme(skin), layout and language of keyboard. guys are working with customers and hear theirs voice so any suggestions might be accepted.
I understand that there are several ways to blend XNA and WPF within the same application. I find it enticing to use WPF for all GUI and HUD stuff in my XNA games. Does anyone have any practical experience on how well this approach works in real life using .NET 3.5 SP1 ? Any pitfalls (such as the "airspace problem")? Any hint on what appoach works best?
There is an addition in 3.5 SP1 that allows better interaction between DirectX and WPF (D3DImage), and one way to get to that is through XNA.
Here are some details:
http://jmorrill.hjtcentral.com/Default.aspx?tabid=428&EntryID=259
XNA integration is high on our list of things to add to WPF so we're looking in to this for future versions. Stay tuned (to GregSc's blog) for the details as they become available.
Ian Ellison-Taylor
Read more about this here
Thamir Khason presented a excellent session about WPF/XNA/Silverlight at Tech-ed... Here is his slides:
http://blogs.microsoft.co.il/blogs/tamir/archive/2008/04/14/my-teched-08-presentation-slides-download.aspx
PS. This was quite impressive to see... he had a game that ran on the xbox. On his desktop using WPF to host XNA and ons his mobile phone using silverlight all playing against each other!!!
You want to use a D3DImage, but D3DImage works different on windows XP vs windows Vista or 7.
On Vista or 7, you create a NON-lockable renderTarget to use with the D3DImage & you use a Direct3D9EX Device.
On XP, you create a lockable renderTarget to use with the D3DImage & use a normal Direct3D9 Device.
Also insted of using XNA it might be better to use SlimDX if your just making this for the PC. SlimDX is not lacking any Direct3D features & supports Direct3D 9, 10 & 11.
http://slimdx.org/
I personally would advise against trying to do this integration. I know what you're going for ... the ease of defining GUI/HUD elements in WPF greatly outweighs trying to do the same in just plain old XNA. However, think realistically of the time you'll spend trying to enable this scenario vs. how much you'd save if you just did everything "natively" in XNA. Also (and this may not be an issue for you), WPF isn't supported on the xbox or zune ... so you'd be limiting yourself :-)
Hey I know this is a while after you posted but if you are still looking for a WPF solution for XNA you may want to keep an eye on http://red-badger.com/product. The XPF soloution puts wpf into XNA. SO have a look, at the moment it is free as it is in beta but that will be changing as they add more components