Is it possible to use DirectX 10 (I am using SlimDX) with WPF's D3DImage? The only examples and docs I can find only show using DX9 surfaces.
Yes, you can use DirectX 10, 11, and DirectWrite using the D3DImage in WPF by creating your render target surface as shared, and then creating a DX9 texture based on that shared texture handle to use in WPF.
This means that essentially you can use 10, 11, and DirectWrite the same way you use DX9 with no additional overhead, and no airspace issues.
A sample WPF project with DX9, DX10, DX11, and DirectWrite integration can be found referenced in this blog post here:
http://blogs.windowsclient.net/rob_relyea/archive/2010/04/30/gizmodo-posts-wpf-direct2d-sample-wow.aspx
The Microsoft Code Pack contains a thin managed wrapper for Windows 7 components including DX9, DX10, DX11 and DirectWrite in addition to various other unmanaged libraries in Windows 7.
The SurfaceQueueInteropHelper is a WPF control that manages automatically creating DX9, 10, and 11 contexts in WPF and managing D3DImage updating and various other aspects of the rendering system including device lost events.
Not out of the box as far as I know. WPF is based on DirectX, but as WPF is also supported on Windows XP it's based on DirectX 9.
I do know that it's possible to use DirectX 10 with WPF, but then your application won't be able to run on XP.
There's a library for WPF called Bling which supports DirectX 10 (on Vista and Windows 7) which might be of interest to you. You can find it here. I don't know how mature it is though.
Also, I ran into this blog (mostly in french) who speaks about using DirectX 10 with WPF.
Lastly there's a good introduction to using D3DImage with DirectX over at CodeProject
I know this doesn't exactly answer your question, but I thought I'd share it with you anyways. Best of luck.
If you're willing to use SlimDX for the DirectX calls, you can try SlimDXControl (slimdxcontrol.codeplex.com) -- it is a WPF content control I wrote which explicitly only supports D3D10 instead of '9.
-mpg
Related
Does it perform drawing by itself, or uses the native UI components provided by Windows in any way?
WPF sort of uses native controls because WPF is the new native way to render controls in Windows - what you consider native is legacy win32, and basically slowly on the way to history.
MS did a lot of optimization in DirectX to allow WPF efficiently to render using the GPU. This is a new "native" interface that is also used to render the Vista upward AERO interface. WPF goes directly to a native layer that then does whatever it can in the GPU - including text rendering.
Now, the reall tricky part in your question is "native UI components provided by windows in ANY MEANS" - well, these low level functions are provided by Windows, so the answer is yes. Primitive drawing operations in a new API were added, but they were added specifically FOR WPF, which is now considered to be sort of the new "native windows presentation layer". MS is slowly moving away from the Win32 API towards WPF for generic presentations (Direct X etc. stays around - WPF is way too generic to be usable for example for high performance first person shooters). As such, given WPF is the new "native components layer", the question gets really tricky to answer ;)
In WPF you can skin all of the controls in whatever way you please by overriding the templates. You absolutely can't do this with win32 controls, so therefore it can't use them.
It uses DirectX 9 to perform all its drawing. It doesn't use WinForms controls
I'd like to draw a high-framerate (30fps+) graph/chart in a Windows Forms app.
How?
Windows Forms gets TERRIBLE frame rates drawing a clear-background drawing over a window.
(I come from the land of GNU, so I apologize if this is obvious.)
If you're using Windows Forms (as said in your question):
If you need to get >30FPS, you'll probably need to change to a different technology. GDI+ drawing is not too efficient.
DirectX would work well for this. You can do the charting in Direct3D using DirectX embedded in a Window. SlimDX is a good way to do this from C#.
That being said, you tagged this with WPF - if you're using WPF, everything is retained mode graphics, so there should be no "clear-background drawing" required. You would just put in the chart elements as needed. In that case, 30FPS should be doable.
Running full tilt I get about 180FPS using a System::Windows::Forms::DataVisualization::Charting::Chart plotting 128bins of an FFT using a 'FastLine' style for the series of data. That's running on an Intel Core 2 Duo (2.53Ghz) IBM Thinkpad.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What is the difference between WPF and Silverlight application?
What are the exact differences between WPF and Silverlight?
That's an extremely broad question. My company recently wrote a whitepaper outlining the differences between the two technologies, and it's around 70 pages. Unfortunately, it's not published yet, or I'd give you the link.
EDIT: As promised, here's the link
to the whitepaper on Codeplex:
http://wpfslguidance.codeplex.com/
However, I'll try to summarize.
WPF is a thick Windows client platform that has access to the full .Net Framework. Silverlight is a browser-based technology that has access to a subset of the .Net Framework (called the CoreCLR). So, you'll notice differences using seemingly every day methods and objects within the framework. For instance, the Split() method on the String class has 3 overrides in Silverlight, but 6 in the .Net Framework. You'll see differences like this a lot.
Within WPF, all visually rendering elements derive from the Visual base class. Within Silverlight, they do not; instead, they derive from Control. Both technologies, however, eventual derive from the DependencyObject class up the hierarchy.
WPF, currently, ships or has available more user controls than Silverlight; though this difference is being mitigated through the Silverlight Toolkit and the upcoming release of Silverlight 3.
WPF supports 3 types of routed events (direct, bubbling, and tunneling). Silverlight supports direct and bubbling only.
There's quite a few data-binding differences that will be somewhat mitigated with the next version of Silverlight. Currently, Silverlight doesn't support the binding mode, OneWayToSource, or Explict UpdateSourceTriggers. In addition, Silverlight defaults to OneWay databinding if none is set, while WPF uses the default mode specified by the dependency property.
Silveright doesn't support MultiBinding.
Silverlight supports the XmlDataProvider but not the ObjectDataProvider. WPF supports both.
Silverlight can only make asynchronous network calls. WPF has access to the full .Net networking stack and can make any type of call. Also, currently, Silverlight supports SOAP, but can not handle SOAP fault exceptions natively (this may change in Silverlight 3).
There are huge differences in Cryptography (Silverlight has 20 classes in the namespace, while WPF has access to 107). Basically, Silverlight supports only 4 hashing algorithms and the AES encryption protocol.
Silverlight doesn't yet support: Commanding, Validation, Printing, XPS Documents, Speech, 3D, Freezable objects, or InterOp with the Windows Desktop; all of which are available in WPF.
Silverlight supports browser interop, more media streaming options including timeline markers, and Deep Zoom. WPF doesn't support these features yet.
This is by no means complete as I was trying to reduce a 70-page document into bullet points.
Finally, even with all these differences, Microsoft is trying to close the gap between the two technologies. The Silverlight Toolkit and the WPF Toolkit both address some of the shortcomings of each technology. Silverlight 3 will be adding many features not currently available (such as element-to-element data binding). However, due to the differences in the core libraries, there will always be some Framework differences.
WPF is a Windows desktop technology for developing Windows application in the .Net framework.
Silverlight is a web technology, that is fully supported by a browser plugin on both Windows and MAC (in a similar fashion to Flash). There is also a plugin for running Silverlight on Linux (Moonlight).
While there are similarities between the functionality provided by both WPF and Silverlight (in terms of user interface components and support for XAML) Silverlight is a much small framework, containing a subset of WPF functionality. Newer versions of Silverlight actually contain some functionality not found in WPF, so it is no longer a true subset.
Things that WPF has that Silverlight doesn't: Full 3d engine based on DirectX, Windows integration such as Windows 7 taskbar thumbnails and system registry availability as well as access to the full .NET Framework including Oracle database support. Also, SL runs in a secure sandbox that prevents access to things such as the entire file system where WPF apps can run full trust with complete system access.
As mentioned above, SL pioneered some technologies such as the VisualStateManager which are making their was secondarily into WPF through the Microsoft supported WPF toolkit.
If you're looking to gauge which technology is right for your project here's a simple way to look at it: If you're writing an app that's meant to run while disconnected from the web, or if you're writing an app that needs access to Windows specific features like the ones listed above then WPF is the way to go. For platform-agnostic, web enabled apps Silverlight is an appropriate choice. Hth.
You could say that it is [VERY] roughly analogous to the difference between Flex and Adobe Air, but that is somewhat misleading.
WPF refers to the set of technologies (exposed via APIs) that .NET Framework 3.0 and above users have access to in order to draw to the screen.
Many of the WPF APIs are available for Silverlight apps.
There are, of course many other APIs besides WPF that are available under Silverlight since SL apps will need to do a lot more than just draw on the screen.
I just installed visio, and the installer almost seemed like it was built in flash.
The buttons kinda glowed when I hovered over them, and when I clicked on 'continue' the form phased out in a cool way.
I'm assuming it was built in WPF.
Anyhow, so are WPF more flash-like (visually speaking).
Do they have new properties where you can make forms phase out nicely/smoothly compared to winforms?
Disclaimer: I work for Microsoft. However, I don't work on Visio, WPF, CLR or Silverlight team. So, the following is my personal take on these technologies. If you want to quote me, don't do it implying it's the official Microsoft position. :-))
Update: Anything I say below about Flash/Flex/AIR might be wrong, as I have not worked with these technologies and what I know about them is based on what I read on the intertubes. :-) If you notice anything wrong, just shout in the comment and I'll correct it.
To the best of my knowledge, the Visio installer is not built with WPF. It's all unmanaged code; it's just people took a lot of care to make it really polished.
WPF is the new UI platform for building standalone applications for the Windows OS. It supports a declarative UI language - XAML, and related CLR types to program against. WPF is a different platform than WinForms, although it is possible to build applications that mix UI built with both. WPF supports a lot of things that WinForms does not, like bitmap effects, animations, control styling and so on and exposes them both in XAML or through code. Also, WPF relies heavily on vector graphics, as opposed to the pixel graphics in WinForms. In short, WPF is quite powerfull and allows building very snazzy UI. (Don't take my word for it, though, as I am biased; go check around for what people are saying about it or buiding with it. :-))
WPF and WinForms do not compete with Flash/Flex. WPF and WinForms are both UI frameworks for building standalone client applications. As far as I know, Flash/Flex are frameworks for building rich internet applications - RIA (though lately people started interpreting this abbreviation as rich interactive applications).
Adobe did come up with AIR about half a year (or maybe a year) ago, which allows building standalone client applications, so you could say that Adobe is trying to position Flash/Flex/AIR to compete with WPF. Of course, that's my take on it and I doubt Adobe's official positiong is anything like that.
If you want to compare particular MS technnologies with Flash/Flex, take a look at Silverlight - it's the MS RIA platform.
Silverlight is related to WPF in the sense that they share XAML and the corresponding CLR types. Silverlight supports only a subset of what WPF offers, though, as it is not targeting Windows OS only and thus is limited by the fact that it has to be portable.
Quick update to reflect the changes in the year since I've written the answer :-)
With Silverlight 3 shipped, SL and WPF are getting even closer and sharing bigger set of supported features. In addition, most of the new XAML controls are built for platform at the same time. Thus, SL/WPF are getting to a point of singularity...
Also, SL 3 supports out-of-browser applications. In that sense, SL is not only starting to compete with Flash/Flex, but it is also encroaching on AIR's turf.
And no, I still don't work on the WPF or Silverlight team. :-)
WPF is being used as a replacement for WinForms, and as a competitor to Flash in the form of Silverlight. WPF consists of an entirely new object model that sits on top of DirectX (at least the desktop version). You can create WPF windows, controls, etc, entirely using C# or another .Net language just like you can render WinForms. However, Microsoft has also created a markup language called XAML (eXensible Application Markup Language). Nodes in an XAML document (XML) map to objects in a similar fashion to the way ASP.Net maps to web controls. XAML typically exists in a .Net project alongside a code-behind style C# file (or VB.Net or whatever). The C# file interacts with the objects generated by the XAML. This is fairly consistent with the "graphics via markup, logic via code" model that Microsoft and others are pushing.
One of the overlooked features when discussing WPF is the completely awesome data-binding that Microsoft wrote for WPF. The new data binding framework is a quantum leap beyond Windows Forms 2.0 data-binding. Microsoft added a couple of new interfaces that make it much easier to make an object or collection emit data-biding events properly. They also provided a very rich set of data-binding classes. You can bind anything to just about anything else. You can bind one-way data to control, control to data, two-way control to data and back, control to control, etc.
Back on the graphics side of the house, WPF makes it fairly easy to make an existing control look like anything. WP lets you compose your own template for what a class of buttons should look like, or one button, or all buttons. Or radio buttons. Or labels. You get my drift. Imagine if CSS included the ability to define what an input button would look like using other HTML controls.
They also provide a number of layout controls. You can continue to use exact positioning like in WinForms, or you can leverage of variety of techniques to make your window act more like a web page that grows and shrinks with resizing, etc.
The downsides: It is too easy to create spectacular effects that crawl on slower machines. Some of the graphics do not take advantage of hardware of graphics cards, though Microsoft has incrementally improved support for this. I believe when 3.0 first came out drop shadows were rendered purely using software. I think 3.5 or 3.5 SP1 changed it so that WPF would utilize graphics hardware for the task. Microsoft has said they will continue to enhance WPF in this fashion.
WPF is .Net 3.0 and above, which runs on XP SP2, Vista, and Servers 03 & 08. So don't plan on deploying WPF to a customer with Win2k desktops.
Summary: If you are doing desktop programming in .Net, you should be doing it in WPF unless you are targeting Win2k. You can avoid the downsides of WPF, and there are many upsides. Microsoft will probably throw away WinForms in some future release, or at very least you will stop seeing new features, etc.
As far as Silverlight goes, the betas for SL 2.0 look good. I think that Silverlight will require some wide-spread adoption. Microsoft has already tried to get this going. The NBC Olypmics site used Silverlight, and Major League Baseball uses it for its MLB.tv product. As soon as Silverlight gets a good install base I think you will see the Microsoft side of the development world starting swinging away from Flash and to Silverlight.
Edit after using Silverlight 3 and MVVM:
I have moved away from WPF and am doing a lot of Silverlight 3 development. But I think my comments here will still apply to the WPF developer.
I have been using the MVVM pattern in my app (think MVC with a twist). The Microsoft Patterns and Practices team has released a set of libraries known as Prism that supports various aspects of MVVM. There are WPF and Silverlight versions. Take a look at MVVM and Prism if you are going to be doing WPF or Silverlight development.
You can do a lot of flash w/ Winforms, or with custom components. But if you want out-of-the-box bang-whizz availability, WPF is the way to go.
Yeah, I think the intention is to be flash-like, it seems to me that MS has set its sights on taking down Adobe.
The way I see it: WPF is to Flash as WinForms is to Flex. WPF has more emphasis on vectors and states than on programming.
Under Windows XP WPF true 3D content (which is usually displayed using the Viewport3D control) looks extremely ugly because it is by default not antialiased as the rest of the WPF graphics are. Especially at lower resolution the experience is so bad that it can not be used in production code.
I have managed to force antialiasing on some Nvidia graphics cards using the settings of the driver. Unfortunately, this sometimes yields ugly artifacts and only works with specific cards and driver versions. The official word from Microsoft on this regard is that antialiased 3D is generally not supported under Windows XP and the artifact I see result from the fact that WPF already does its own antialiasing (on XP only for 2D).
So I was wondering if there is maybe some other secret trick that lets me force antialiasing on WPF 3D content under Windows XP.
Have you tried this (from your thread on MSDN forums)?
Well, it seems the reference in the MSDN link above incorrectly specify the affected registry root key. In MSDN it is specified as HKEY_CURRENT_USER, while the correct root key should be HKEY_LOCAL_MACHINE. I've tried setting up the HKEY_LOCAL_MACHINE\Software\Microsoft\Avalon.Graphics\MaxMultiplesampleType to '4' and I can get antialiasing for my WPF Application on XP.
The feeling I get from Matthew MacDonald's Pro WPF Windows Presentation Foundation in .NET 3.0 is that it's not possible:
There's one exception to WPF's software support. Due to poor driver support, WPF only performs antialiasing for 3-D drawings if you're running your application on Windows Vista (and you have a native Windows Vista driver for your video card).
I've never seen anything to suggest that you can enable AA in WPF 3D on anything but Vista, but if there is a way it's new to me and I'd love to know as well!
Does your video card support Shader 2.0? You can refer to this wiki page to see if it does...