A. WHY WPF: WPF is framework to build application for windows. It is designed for .NET influenced by modern display technologies like HTML and Flash and hardware acceleration.
Don’t take WPF as replacement for window forms which has been hot favorite for developers like us for building application for windows.
1. Life before WPF:
It will be inevitable not to look back and see what a standard windows application replies on two well worn parts of windows operation system to create its user interface.
a) User32: provides familiar windows look and feel for element.
b) GDI/GDI +: provides drawing support for rendering shapes, text, images etc,
Newer framework just provides a wrapper to interacting with User32 or GDI. These API as wrappers just provide improvement in efficiently, reduce complexity.
The problem with User32 and GDI are that they are designed decade back and couldn’t catch up well with advancement of hardware i.e. graphics card, introduction to high resolution screens. So we were still using a decade old technology and with on growing hardware. So Microsoft created one way around the limitations of the User32 and GDI/GDI+ libraries: DirectX, which was used for creating games on the windows platform. The ultimate purpose was to give hardware acceleration to DirectX from video card of computer, to compute complex textures, special effects, some special effects, 3D graphics etc.
Problem with DirectX was that due to its raw complexity, it was almost never used in traditional types of Windows applications (such as business software).
Another factor which window forms based on above named technologies suffered was resolution.
Traditional Windows applications are bound by certain assumptions about resolution. We usually assume a standard monitor resolution (such as 1024 by 768 pixels), design our windows with that in mind, and try to ensure reasonable resizing behavior for smaller and larger dimensions
2. Wind of Change, WPF: WPF changes all this and is fundamentally different from window forms. WPF’s underlying technology isn’t GDI/GDI+, instead it uses DirectX. So WPF uses DirectX no matter what type of user interface we create. So it’s like whether we are creating complex 3D graphics or just drawing a button , all the drawing work have to pass through DirectX pipeline. Since WPF relies on DirectX, now we can take advantage of hardware acceleration as well , which means this will hand off much work as possible to the GPU(graphics processing unit ) which is dedicated processor on video card, and our CPU(central processing unit ) could do some rest. J
3. Do WPF rely on User32? WPF still relies on User32 for certain services, such as handling and routing input and sorting out which application owns which portion of screen real estate. However, all the drawing is funneled through DirectX.
This is the most significant change in WPF. WPF is not a wrapper for GDI/GDI+. Instead, it’s a replacement—a separate layer that works through DirectX.
4. What does it means” hardware acceleration”: It is to offload as much of the work as possible on the video card so that complex graphics routines are render-bound (limited by the GPU) rather than processor-bound (limited by our computer’s CPU). That way, we keep the CPU free for other work, we make the best use of our video card, and we are able to take advantage of performance increases in newer video cards as they become available.
5. How Hardware acceleration is achieved with WPF: WPF is intelligent enough to use hardware optimizations where possible by the use of drivers, but it has a software fallback for everything. So if we run a WPF application on a computer with a legacy video card, the interface will still appear the way we designed it. Of course, the software alternative may be much slower, so we’ll find that computers with older video cards won’t run rich WPF applications very well.
6. Resolution independence: The problem with the user interface in traditional Windows applications that they aren’t scalable. As a result, if we use a high monitor resolution that crams pixels in more densely, our application windows become smaller and more difficult to read. This is particularly a problem with newer monitors that have high pixel densities and run at correspondingly high resolutions.
WPF doesn’t suffer from this problem because it renders all user interface elements itself, from simple shapes to common controls such as buttons. As a result, if we create a button that’s 1 inch wide on our computer monitor, it can remain 1 inch wide on a high-resolution monitor—WPF will simply render it in greater detail and with more pixels. Most importantly, we need to realize that WPF bases it’s scaling on the system DPI setting, not the DPI of our physical display device.
So how does WPF determine how big an application window should be? The short answer is that WPF uses the system DPI setting when it calculates sizes.
7. Not possible to integrate or overlap technologies like User32, GDI, DirectX ,Flash etc.
One of the challenges of the desktop world is with these technologies is of mixing them altogether. Infact whatever shortcoming which discussed above in the article already has the solutions before WPF come into the picture. Say wants to get design ability benefit of web, well we nobody is stopping using HTML in desktop applications. Want scalable animated graphics, well flash does that and we can use it in our desktop application. Need support of accessibility in the software, well Win32 do the work for us? And when it comes to take full advantage of graphics hardware, well we can use DirectX.
But the problem arises when we need some combination of these features; say I want to use visual capability of flash with accessibility usability of classic Win32; well it’s tough to do. Need to put Wind32 buttons listbox inside DirectX scene, well tough m we can’t do that.
Problem here is that each of these technologies is isolated, we can combine these technologies, but we have to partition our screen, so that areas rendered by DirectX do not overlap area rendered by HTML. We can make flash content overlap with HTML, but there is issue of visual handling, we do not get proper overlap, there is some hack. And in general we can’t apply element of one technology to a different technology, there is no any integration across these pieces.
WPF solves this, as it is described as single integrated solution. Its unique feature is integration of all these unique features technologies, i.e. this composibility is single best feature.
B. WHAT is WPF? A high level API:
WPF is the beginning of the future of Windows development. In time, it will become a system like User32 and GDI/GDI+, on top of which more enhancements and higher-level features are added.
1. WPF Evolution: WPF exists in two versions:
a. WPF 3.0: Along with WCF, WWF all three together were called the .NET framework 3.0
b. WPF 3.5: These have minor refinement with some bug fixing and performance improvement.
c. WPF 4.0:
Differences between 3.0 and 3.5 are below;
a. Significant difference between WPF 3.0 and 3.5 is design-time support.
b. The .NET Framework 3.0 was released without a corresponding version of Visual Studio. The .NET Framework 3.5 was released in conjunction with Visual Studio 2008, and as a result, it offers much better design-time support for building WPF applications.
2. Visual Studio support and WPF: Visual Studio 2008 allows us to create applications that are specifically designed to work with .NET 2.0, .NET 3.0, or .NET 3.5.
To understand how the Visual Studio multitargeting system works, we need to know a bit more about how .NET 3.5 is structured. Essentially, .NET 3.5 is built out of three separate pieces—a copy of the original .NET 2.0 assemblies, a copy of the assemblies that were added in .NET 3.0 (for WPF, WCF, and WF), and the new assemblies that were added in .NET 3.5 (for LINQ and a number of miscellaneous features). However, when we create and test an application in Visual Studio, we are always using the .NET 3.5 assemblies. When we choose to target an earlier version of .NET, Visual Studio simply uses a subset of the .NET 3.5 assemblies.
3. WPF Architecture: WPF uses a multilayered architecture. At the top, our application interacts with a high-level set of services that are completely written in managed C# code. The actual work of translating.NET objects into Direct3D textures and triangles happens behind the scenes, using a lower level unmanaged component called milcore.dll.
Milcore.dll is implemented in unmanaged code because it needs tight integration with Direct3D and because it’s extremely performance-sensitive.
Let us discuss in detail about role of each DLL classes.
1. PresentationFramework.dll holds the top-level WPF types, including those that represent windows, panels, and other types of controls. It also implements higher-level programming abstractions such as styles. Most of the classes we’ll use directly come from this assembly.
2. PresentationCore.dll holds base types, such as UIElement and Visual, from which all shapes and controls derive. If we don’t need the full window and control abstraction layer, we can drop down to this level and still take advantage of WPF’s rendering engine.
3. WindowsBase.dll holds even more basic ingredients that have the potential to be reused outside of WPF, such as DispatcherObject and DependencyObject, which introduces the plumbing for dependency properties.
4. Milcore.dll is the core of the WPF rendering system and the foundation of the Media Integration Layer (MIL). Its composition engine translates visual elements into the triangle and textures that Direct3D expects. Although milcore.dll is considered a part of WPF, it’s also an essential system component for Windows Vista.
5. WindowsCodecs.dll is a low-level API that provides imaging support (for example, processing, displaying, and scaling bitmaps and JPEGs).
6. Direct3D is the low-level API through which all the graphics in a WPF are rendered.
7. User32 is used to determine what program gets what real estate. As a result, it’s still involved in WPF, but it plays no part in rendering common controls.
4. WPF some features: If the only thing WPF offered was hardware acceleration through DirectX, it would be a compelling improvement, but not a revolutionary one. But WPF actually includes a basket of high-level services designed for application programmers.
a. A web-like layout model. Rather than fix controls in place with specific coordinates, WPF emphasizes flexible flow layout that arranges controls based on their content. The result is a user interface that can adapt to show highly dynamic content or different languages.
b. A rich drawing model. Rather than painting pixels, in WPF we deal with primitives—basic shapes, blocks of text, and other graphical ingredients. We also have new features, such as true transparent controls, the ability to stack multiple layers with different opacities, and native 3-D support.
c. Animation as a first-class programming concept. Yes, we could use a timer to force a form to repaint it. But in WPF, animation is an intrinsic part of the framework. We define animations with declarative tags, and WPF puts them into action automatically
d. Styles and templates. Styles allow us to standardize formatting and reuse it throughout our application. Templates allow us to change the way any element is rendered, even a core control such as the button. It’s never been easier to build modern skinned interfaces.
e. Page-based applications. Using WPF, we can build a browser-like application that lets we move through a collection of pages, complete with forward and back navigation buttons. WPF handles the messy details, such as the page history. We can even deploy our project as a browser-based application that runs right inside Internet Explorer.
C. WHEN to use WPF: WPF is the platform for the future of Windows user interface development. However, it won’t displace Windows Forms overnight. Windows Forms is in many ways the culmination of the display technology built on GDI/GDI+ and User32. It’s more mature than WPF and still includes features that haven’t made their way into the WPF toolkit (such as the WebBrowser control, the DataGridView control, and the HelpProvider component).
So which platform should we choose when we begin designing a new Windows application?
a. If we are starting from the ground up, WPF is an ideal choice and it offers the best prospects for future enhancements and longevity.
b. Similarly, if we need one of the features that WPF provides and Windows Forms does not—such as 3D drawing or page-based applications—it makes sense to make the shift. On the other hand, if we have a considerable investment in a Windows Forms–based business application, there’s no need to recode our efforts.
c. WPF is an especially great platform to use if our applications involve various media types. For example, if we need to incorporate video, or documents, or 3D content, or animated transitions between a sequence of images, or a combination of any of the above.
d. WPF is also great if we need to create a skinned user interface, or if we need to bind to XML data, or dynamically load portions of a user interface from a Web service, or want to create a desktop application with a Web-like navigation style.
e. If we are building applications with no need for the extensive modern functionality in WPF, then there is no compelling reason to leave behind a time-tested developer-approved platform like WinForms
f. Lastly, don’t forget that it is possible to use WPF controls in a WinForms app, and WinForms controls in a WPF app. If we have a substantial investment in a WinForms code-base, but want to use some aspect(s) of WPF, we can leverage the interop support to make that possible.
Thanks for reading