A. WHY WPF: WPF is a framework to build application for windows. It is
designed for .NET influenced by modern display technologies like HTML, Flash, and hardware acceleration.
Don't take WPF as replacement for Windows Forms, which has been a hot favorite for
developers like us for building application for Windows.
- Life before WPF:
It will be inevitable 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 a familiar Windows look and feel for elements.
b) GDI/GDI +: provides drawing support for rendering shapes, text, images etc,
Newer frameworks just provide a wrapper for interacting with User32 or GDI. These APIs as wrappers just provide improvements in efficiently and reduce complexity.
The problem with User32 and GDI are that they are designed a decade back and couldn't catch up well with the advancement of hardware i.e. graphics cards and the introduction of high resolution screens. So we were still using a decade old technology 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 the video card of a computer, to compute complex textures, special effects, some special effects, 3D graphics etc.
The 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 made Window Forms based on the above named technologies suffer 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.
- 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 whether we are creating complex 3D graphics or just drawing a button, all of the drawing work has 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 as much work as possible to the GPU(graphics processing unit) which is a dedicated processor on the video card, and our CPU(central processing unit) could do some rest.
- 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.
- What does it mean to "hardware accelerate": 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.
- 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.
- Resolution independence: The problem with the user interface in traditional Windows applications is 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 of the 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.
- Not possible to integrate or overlap technologies like User32, GDI, DirectX, Flash etc.
One of the challenges of the desktop world with these technologies is mixing them altogether. Infact whatever shortcomings which were discussed above already had solutions before WPF come into the picture. Say we want to get the design ability benefit of web? Well nobody is stopping us from using HTML in desktop applications. Want scalable animated graphics? Well Flash does that and we can use it in our desktop applications. Need support of accessibility in the software? Well Win32 does the work for us. And when it comes to taking 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 the visual capability of Flash with accessibility and usability of classic Win32; well it's tough to do. Need to put Wind32 buttons listbox inside DirectX scene? Well tough, we can't do that.
The 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 the issue of visual handling, we do not get proper overlap, there is some hack. And in general we can't apply the element of one technology to a different technology, there is no integration across these pieces.
WPF solves this, as it is described as a 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.
- 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 had minor refinement with some bug fixing and performance improvements.
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.
- 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 WWF), 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.
- 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.
- 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?
- If we are starting from the ground up, WPF is an ideal choice and it offers
the best prospects for future enhancements and longevity.
- 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.
- 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.
- 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.
- 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
- 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
Cheers.
http://vishalnayan.wordpress.com/
Sam HobbseditedPosted Sep 5, 2011, 3:05 AMEdited Sep 5, 2011, 3:18 AM
The original need for Directx was because most games programmers that did graphics for the old 16-bit Windows did not use Windows for graphics. Since 16-bit Windows executed on top of DOS, games programmers could and did use the hardware directly. They could not do that in 32-bit Windows and 32-bit Windows was too slow for games programmers. Directx provided the ability to work more directly with the hardware than Windows GDI provided but that direct use of the hardware made Directx too complicated when there is not a need for graphics as much as other applications such as games need to. Note that Directx was introduced in 1995 when Windows was ten years old, so it seems unlikely that it was created to overcome any limitations of GDI caused by newer hardware.
Kamal VermaPosted Sep 4, 2011, 11:59 PM
Nice Article.... Vishal